| Message ID | 20210517225714.498032-1-eric.snowberg@oracle.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add additional MOK vars | expand |
On Mon, May 17, 2021 at 06:57:11PM -0400, Eric Snowberg wrote: > This series is being sent as an RFC. I am looking for feedback; if > adding additional MOK variables would be an acceptable solution to help > downstream Linux distros solve some of the problems we are facing? > > Currently, pre-boot keys are not trusted within the Linux boundary [1]. > Pre-boot keys include UEFI Secure Boot DB keys and MOKList keys. These > keys are loaded into the platform keyring and can only be used for kexec. > If an end-user wants to use their own key within the Linux trust > boundary, they must either compile it into the kernel themselves or use > the insert-sys-cert script. Both options present a problem. Many > end-users do not want to compile their own kernels. With the > insert-sys-cert option, there are missing upstream changes [2]. Also, > with the insert-sys-cert option, the end-user must re-sign their kernel > again with their own key, and then insert that key into the MOK db. > Another problem with insert-sys-cert is that only a single key can be > inserted into a compressed kernel. > > Having the ability to insert a key into the Linux trust boundary opens > up various possibilities. The end-user can use a pre-built kernel and > sign their own kernel modules. It also opens up the ability for an > end-user to more easily use digital signature based IMA-appraisal. To > get a key into the ima keyring, it must be signed by a key within the > Linux trust boundary. > > Downstream Linux distros try to have a single signed kernel for each > architecture. Each end-user may use this kernel in entirely different > ways. Some downstream kernels have chosen to always trust platform keys > within the Linux trust boundary. In addition, most downstream kernels > do not have an easy way for an end-user to use digital signature based > IMA-appraisal. > > This series adds two new MOK variables to shim. The first variable > allows the end-user to decide if they want to trust keys contained Nit: would be nice to just say "what it is" instead "what it allows". > within the platform keyring within the Linux trust boundary. By default, > nothing changes; platform keys are not trusted within the Linux kernel. > They are only trusted after the end-user makes the decision themself. > The end-user would set this through mokutil using a new --trust-platform > option [3]. This would work similar to how the kernel uses MOK variables > to enable/disable signature validation as well as use/ignore the db. > > The second MOK variable allows a downstream Linux distro to make ... > better use of the IMA architecture specific Secure Boot policy. This > IMA policy is enabled whenever Secure Boot is enabled. By default, this > new MOK variable is not defined. This causes the IMA architecture > specific Secure Boot policy to be disabled. Since this changes the > current behavior, it is placed behind a new Kconfig option. Kernels > built with IMA_UEFI_ARCH_POLICY enabled would allow the end-user > to enable this through mokutil using a new --ima-sb-enable option [3]. > This gives the downstream Linux distro the capability to offer the > IMA architecture specific Secure Boot policy option, while giving > the end-user the ability to decide if they want to use it. > > I have included links to both the mokutil [3] and shim [4] changes I > made to support this new functionality. > > Thank you and looking forward to hearing your reviews. > > [1] https://lore.kernel.org/lkml/1556221605.24945.3.camel@HansenPartnership.com/ > [2] https://lore.kernel.org/patchwork/cover/902768/ > [3] https://github.com/esnowberg/mokutil/tree/0.3.0-mokvars > [4] https://github.com/esnowberg/shim/tree/mokvars > > Eric Snowberg (3): > keys: Add ability to trust the platform keyring > keys: Trust platform keyring if MokTrustPlatform found > ima: Enable IMA SB Policy if MokIMAPolicy found > > certs/system_keyring.c | 19 ++++++++- > include/keys/system_keyring.h | 10 +++++ > security/integrity/ima/Kconfig | 8 ++++ > security/integrity/ima/ima_efi.c | 24 ++++++++++++ > .../platform_certs/platform_keyring.c | 39 +++++++++++++++++++ > 5 files changed, 99 insertions(+), 1 deletion(-) > > -- > 2.18.4 > > /Jarkko
Hi Eric, On Mon, 2021-05-17 at 18:57 -0400, Eric Snowberg wrote: > This series is being sent as an RFC. I am looking for feedback; if > adding additional MOK variables would be an acceptable solution to help > downstream Linux distros solve some of the problems we are facing? > > Currently, pre-boot keys are not trusted within the Linux boundary [1]. > Pre-boot keys include UEFI Secure Boot DB keys and MOKList keys. These > keys are loaded into the platform keyring and can only be used for kexec. > If an end-user wants to use their own key within the Linux trust > boundary, they must either compile it into the kernel themselves or use > the insert-sys-cert script. Both options present a problem. Many > end-users do not want to compile their own kernels. With the > insert-sys-cert option, there are missing upstream changes [2]. Also, > with the insert-sys-cert option, the end-user must re-sign their kernel > again with their own key, and then insert that key into the MOK db. > Another problem with insert-sys-cert is that only a single key can be > inserted into a compressed kernel. > > Having the ability to insert a key into the Linux trust boundary opens > up various possibilities. The end-user can use a pre-built kernel and > sign their own kernel modules. It also opens up the ability for an > end-user to more easily use digital signature based IMA-appraisal. To > get a key into the ima keyring, it must be signed by a key within the > Linux trust boundary. > > Downstream Linux distros try to have a single signed kernel for each > architecture. Each end-user may use this kernel in entirely different > ways. Some downstream kernels have chosen to always trust platform keys > within the Linux trust boundary. In addition, most downstream kernels > do not have an easy way for an end-user to use digital signature based > IMA-appraisal. > > This series adds two new MOK variables to shim. The first variable > allows the end-user to decide if they want to trust keys contained > within the platform keyring within the Linux trust boundary. By default, > nothing changes; platform keys are not trusted within the Linux kernel. > They are only trusted after the end-user makes the decision themself. > The end-user would set this through mokutil using a new --trust-platform > option [3]. This would work similar to how the kernel uses MOK variables > to enable/disable signature validation as well as use/ignore the db. > > The second MOK variable allows a downstream Linux distro to make > better use of the IMA architecture specific Secure Boot policy. This > IMA policy is enabled whenever Secure Boot is enabled. By default, this > new MOK variable is not defined. This causes the IMA architecture > specific Secure Boot policy to be disabled. Since this changes the > current behavior, it is placed behind a new Kconfig option. Kernels > built with IMA_UEFI_ARCH_POLICY enabled would allow the end-user > to enable this through mokutil using a new --ima-sb-enable option [3]. > This gives the downstream Linux distro the capability to offer the > IMA architecture specific Secure Boot policy option, while giving > the end-user the ability to decide if they want to use it. > > I have included links to both the mokutil [3] and shim [4] changes I > made to support this new functionality. > > Thank you and looking forward to hearing your reviews. This patch set addresses two very different issues - allowing keys on the platform keyring to be trusted for things other than verifying the kexec kernel image signature, overwriting the arch specific IMA secure boot policy rules. The only common denominator is basing those decisions on UEFI variables, which has been previously suggested and rejected. The threat model hasn't changed. The desire for allowing a single local CA key to be loaded onto a trusted keyring is understandable. A local CA key can be used to sign certificates, allowing them to be loaded onto the IMA keyring. What is the need for multiple keys? Making an exception for using a UEFI key for anything other than verifying the kexec kernel image, can not be based solely on UEFI variables, but should require some form of kernel agreement/confirmation. If/when a safe mechanism for identifying a single local CA key is defined, the certificate should be loaded directly onto the secondary keyring, not linked to the platform keyring. The system owner can enable/disable secure boot. Disabling the arch secure boot IMA policy rules is not needed. However, another mechanism for enabling them would be acceptable. thanks, Mimi
> On May 19, 2021, at 8:32 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: > > On Mon, 2021-05-17 at 18:57 -0400, Eric Snowberg wrote: >> This series is being sent as an RFC. I am looking for feedback; if >> adding additional MOK variables would be an acceptable solution to help >> downstream Linux distros solve some of the problems we are facing? >> >> Currently, pre-boot keys are not trusted within the Linux boundary [1]. >> Pre-boot keys include UEFI Secure Boot DB keys and MOKList keys. These >> keys are loaded into the platform keyring and can only be used for kexec. >> If an end-user wants to use their own key within the Linux trust >> boundary, they must either compile it into the kernel themselves or use >> the insert-sys-cert script. Both options present a problem. Many >> end-users do not want to compile their own kernels. With the >> insert-sys-cert option, there are missing upstream changes [2]. Also, >> with the insert-sys-cert option, the end-user must re-sign their kernel >> again with their own key, and then insert that key into the MOK db. >> Another problem with insert-sys-cert is that only a single key can be >> inserted into a compressed kernel. >> >> Having the ability to insert a key into the Linux trust boundary opens >> up various possibilities. The end-user can use a pre-built kernel and >> sign their own kernel modules. It also opens up the ability for an >> end-user to more easily use digital signature based IMA-appraisal. To >> get a key into the ima keyring, it must be signed by a key within the >> Linux trust boundary. >> >> Downstream Linux distros try to have a single signed kernel for each >> architecture. Each end-user may use this kernel in entirely different >> ways. Some downstream kernels have chosen to always trust platform keys >> within the Linux trust boundary. In addition, most downstream kernels >> do not have an easy way for an end-user to use digital signature based >> IMA-appraisal. >> >> This series adds two new MOK variables to shim. The first variable >> allows the end-user to decide if they want to trust keys contained >> within the platform keyring within the Linux trust boundary. By default, >> nothing changes; platform keys are not trusted within the Linux kernel. >> They are only trusted after the end-user makes the decision themself. >> The end-user would set this through mokutil using a new --trust-platform >> option [3]. This would work similar to how the kernel uses MOK variables >> to enable/disable signature validation as well as use/ignore the db. >> >> The second MOK variable allows a downstream Linux distro to make >> better use of the IMA architecture specific Secure Boot policy. This >> IMA policy is enabled whenever Secure Boot is enabled. By default, this >> new MOK variable is not defined. This causes the IMA architecture >> specific Secure Boot policy to be disabled. Since this changes the >> current behavior, it is placed behind a new Kconfig option. Kernels >> built with IMA_UEFI_ARCH_POLICY enabled would allow the end-user >> to enable this through mokutil using a new --ima-sb-enable option [3]. >> This gives the downstream Linux distro the capability to offer the >> IMA architecture specific Secure Boot policy option, while giving >> the end-user the ability to decide if they want to use it. >> >> I have included links to both the mokutil [3] and shim [4] changes I >> made to support this new functionality. >> >> Thank you and looking forward to hearing your reviews. > > This patch set addresses two very different issues - allowing keys on > the platform keyring to be trusted for things other than verifying the > kexec kernel image signature, overwriting the arch specific IMA secure > boot policy rules. The only common denominator is basing those > decisions on UEFI variables, which has been previously suggested and > rejected. The threat model hasn't changed. Could you point me please to the previous discussion on the threat model this change would violate? What I found was [1], which I have tried to solve with this series. Having the ability to update a MOK variable indicates the user is not only root, but also the machine owner. MOK variable updates require both root access to update and then physical presence to set via shim after reboot. This patch set tries to address the "*second* order" Linus requested [2]. > The desire for allowing a single local CA key to be loaded onto a > trusted keyring is understandable. A local CA key can be used to sign > certificates, allowing them to be loaded onto the IMA keyring. What is > the need for multiple keys? We have no control over how many keys an end-user may wish to enroll. They might want to enroll a CA for IMA and a different key for their kernel modules. This is a generic kernel that can serve many different purposes. Think distro kernels - like Fedora, Ubuntu, Oracle Linux, etc. > Making an exception for using a UEFI key for anything other than > verifying the kexec kernel image, can not be based solely on UEFI > variables, but should require some form of kernel > agreement/confirmation. Isn’t that the case today with how MOK variables get set through mokutil and shim? > If/when a safe mechanism for identifying a > single local CA key is defined, the certificate should be loaded > directly onto the secondary keyring, not linked to the platform > keyring. > The system owner can enable/disable secure boot. Disabling the arch > secure boot IMA policy rules is not needed. However, another mechanism > for enabling them would be acceptable. For a distro kernel, disabling the arch secure boot IMA policy rules is needed. Distributions build a single kernel that can be used in many different ways. If we wanted to add a built-in IMA policy for an extra level of security protection, this allows the end-user to opt-in when secure boot is enabled. They are then protected before init is called. Not every user will want this protection; a different user may just want secure boot enabled without the IMA level protection. After going through the mailing list history related to IMA appraisal, is this feature strictly geared towards a custom kernel used for a specific purpose? Do you view it as not being a feature suitable for a generic distribution kernel to offer? [1] https://lore.kernel.org/lkml/1556221605.24945.3.camel@HansenPartnership.com/ [2] https://marc.info/?l=linux-kernel&m=136185386310140&w=2
On Wed, 2021-05-19 at 16:04 -0600, Eric Snowberg wrote: > > On May 19, 2021, at 8:32 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: > > > > On Mon, 2021-05-17 at 18:57 -0400, Eric Snowberg wrote: > >> This series is being sent as an RFC. I am looking for feedback; if > >> adding additional MOK variables would be an acceptable solution to help > >> downstream Linux distros solve some of the problems we are facing? > >> > >> Currently, pre-boot keys are not trusted within the Linux boundary [1]. > >> Pre-boot keys include UEFI Secure Boot DB keys and MOKList keys. These > >> keys are loaded into the platform keyring and can only be used for kexec. > >> If an end-user wants to use their own key within the Linux trust > >> boundary, they must either compile it into the kernel themselves or use > >> the insert-sys-cert script. Both options present a problem. Many > >> end-users do not want to compile their own kernels. With the > >> insert-sys-cert option, there are missing upstream changes [2]. Also, > >> with the insert-sys-cert option, the end-user must re-sign their kernel > >> again with their own key, and then insert that key into the MOK db. > >> Another problem with insert-sys-cert is that only a single key can be > >> inserted into a compressed kernel. > >> > >> Having the ability to insert a key into the Linux trust boundary opens > >> up various possibilities. The end-user can use a pre-built kernel and > >> sign their own kernel modules. It also opens up the ability for an > >> end-user to more easily use digital signature based IMA-appraisal. To > >> get a key into the ima keyring, it must be signed by a key within the > >> Linux trust boundary. > >> > >> Downstream Linux distros try to have a single signed kernel for each > >> architecture. Each end-user may use this kernel in entirely different > >> ways. Some downstream kernels have chosen to always trust platform keys > >> within the Linux trust boundary. In addition, most downstream kernels > >> do not have an easy way for an end-user to use digital signature based > >> IMA-appraisal. > >> > >> This series adds two new MOK variables to shim. The first variable > >> allows the end-user to decide if they want to trust keys contained > >> within the platform keyring within the Linux trust boundary. By default, > >> nothing changes; platform keys are not trusted within the Linux kernel. > >> They are only trusted after the end-user makes the decision themself. > >> The end-user would set this through mokutil using a new --trust-platform > >> option [3]. This would work similar to how the kernel uses MOK variables > >> to enable/disable signature validation as well as use/ignore the db. > >> > >> The second MOK variable allows a downstream Linux distro to make > >> better use of the IMA architecture specific Secure Boot policy. This > >> IMA policy is enabled whenever Secure Boot is enabled. By default, this > >> new MOK variable is not defined. This causes the IMA architecture > >> specific Secure Boot policy to be disabled. Since this changes the > >> current behavior, it is placed behind a new Kconfig option. Kernels > >> built with IMA_UEFI_ARCH_POLICY enabled would allow the end-user > >> to enable this through mokutil using a new --ima-sb-enable option [3]. > >> This gives the downstream Linux distro the capability to offer the > >> IMA architecture specific Secure Boot policy option, while giving > >> the end-user the ability to decide if they want to use it. > >> > >> I have included links to both the mokutil [3] and shim [4] changes I > >> made to support this new functionality. > >> > >> Thank you and looking forward to hearing your reviews. > > > > This patch set addresses two very different issues - allowing keys on > > the platform keyring to be trusted for things other than verifying the > > kexec kernel image signature, overwriting the arch specific IMA secure > > boot policy rules. The only common denominator is basing those > > decisions on UEFI variables, which has been previously suggested and > > rejected. The threat model hasn't changed. > > Could you point me please to the previous discussion on the threat model > this change would violate? What I found was [1], which I have tried to > solve with this series. Having the ability to update a MOK variable > indicates the user is not only root, but also the machine owner. MOK > variable updates require both root access to update and then physical > presence to set via shim after reboot. This patch set tries to address > the "*second* order" Linus requested [2]. The concern is not with the normal way of updating MOK. > > > The desire for allowing a single local CA key to be loaded onto a > > trusted keyring is understandable. A local CA key can be used to sign > > certificates, allowing them to be loaded onto the IMA keyring. What is > > the need for multiple keys? > > We have no control over how many keys an end-user may wish to enroll. > They might want to enroll a CA for IMA and a different key for their > kernel modules. This is a generic kernel that can serve many different > purposes. Think distro kernels - like Fedora, Ubuntu, Oracle Linux, etc. This patch set changes the secondary keyring root of trust, which is currently the builtin or other keys on the secondary keyring. My concern with this change, is that any key on the secondary keyring may then be directly loaded or used to verify other keys being loaded onto the IMA keyring. I really do understand the need for extending the root of trust beyond the builtin keys and allowing end user keys to be loaded onto a kernel keyring, but it needs to be done safely. The first step might include locally signing the MOK keys being loaded onto the secondary keyring and then somehow safely providing the local-CA key id to the kernel. > > > Making an exception for using a UEFI key for anything other than > > verifying the kexec kernel image, can not be based solely on UEFI > > variables, but should require some form of kernel > > agreement/confirmation. > > Isn’t that the case today with how MOK variables get set through > mokutil and shim? > > > If/when a safe mechanism for identifying a > > single local CA key is defined, the certificate should be loaded > > directly onto the secondary keyring, not linked to the platform > > keyring. > > The system owner can enable/disable secure boot. Disabling the arch > > secure boot IMA policy rules is not needed. However, another mechanism > > for enabling them would be acceptable. > > For a distro kernel, disabling the arch secure boot IMA policy rules is > needed. Distributions build a single kernel that can be used in many > different ways. If we wanted to add a built-in IMA policy for an extra > level of security protection, this allows the end-user to opt-in when > secure boot is enabled. They are then protected before init is called. > Not every user will want this protection; a different user may just want > secure boot enabled without the IMA level protection. When secure boot is enabled, the IMA arch policy rules verify the kexec kernel image is properly signed. When CONFIG_MODULE_SIG is not configured, it also verifies kernel modules are properly signed. > After going through the mailing list history related to IMA appraisal, > is this feature strictly geared towards a custom kernel used for a > specific purpose? Do you view it as not being a feature suitable for > a generic distribution kernel to offer? IMA-appraisal is enabled by distros, but requires labeling the filesystem with security.ima xattrs, before loading an appraisal policy. thanks, Mimi > > > [1] https://lore.kernel.org/lkml/1556221605.24945.3.camel@HansenPartnership.com/ > [2] https://marc.info/?l=linux-kernel&m=136185386310140&w=2 > >
> On May 20, 2021, at 6:22 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: > > On Wed, 2021-05-19 at 16:04 -0600, Eric Snowberg wrote: >>> On May 19, 2021, at 8:32 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: >>> >>> On Mon, 2021-05-17 at 18:57 -0400, Eric Snowberg wrote: >>>> This series is being sent as an RFC. I am looking for feedback; if >>>> adding additional MOK variables would be an acceptable solution to help >>>> downstream Linux distros solve some of the problems we are facing? >>>> >>>> Currently, pre-boot keys are not trusted within the Linux boundary [1]. >>>> Pre-boot keys include UEFI Secure Boot DB keys and MOKList keys. These >>>> keys are loaded into the platform keyring and can only be used for kexec. >>>> If an end-user wants to use their own key within the Linux trust >>>> boundary, they must either compile it into the kernel themselves or use >>>> the insert-sys-cert script. Both options present a problem. Many >>>> end-users do not want to compile their own kernels. With the >>>> insert-sys-cert option, there are missing upstream changes [2]. Also, >>>> with the insert-sys-cert option, the end-user must re-sign their kernel >>>> again with their own key, and then insert that key into the MOK db. >>>> Another problem with insert-sys-cert is that only a single key can be >>>> inserted into a compressed kernel. >>>> >>>> Having the ability to insert a key into the Linux trust boundary opens >>>> up various possibilities. The end-user can use a pre-built kernel and >>>> sign their own kernel modules. It also opens up the ability for an >>>> end-user to more easily use digital signature based IMA-appraisal. To >>>> get a key into the ima keyring, it must be signed by a key within the >>>> Linux trust boundary. >>>> >>>> Downstream Linux distros try to have a single signed kernel for each >>>> architecture. Each end-user may use this kernel in entirely different >>>> ways. Some downstream kernels have chosen to always trust platform keys >>>> within the Linux trust boundary. In addition, most downstream kernels >>>> do not have an easy way for an end-user to use digital signature based >>>> IMA-appraisal. >>>> >>>> This series adds two new MOK variables to shim. The first variable >>>> allows the end-user to decide if they want to trust keys contained >>>> within the platform keyring within the Linux trust boundary. By default, >>>> nothing changes; platform keys are not trusted within the Linux kernel. >>>> They are only trusted after the end-user makes the decision themself. >>>> The end-user would set this through mokutil using a new --trust-platform >>>> option [3]. This would work similar to how the kernel uses MOK variables >>>> to enable/disable signature validation as well as use/ignore the db. >>>> >>>> The second MOK variable allows a downstream Linux distro to make >>>> better use of the IMA architecture specific Secure Boot policy. This >>>> IMA policy is enabled whenever Secure Boot is enabled. By default, this >>>> new MOK variable is not defined. This causes the IMA architecture >>>> specific Secure Boot policy to be disabled. Since this changes the >>>> current behavior, it is placed behind a new Kconfig option. Kernels >>>> built with IMA_UEFI_ARCH_POLICY enabled would allow the end-user >>>> to enable this through mokutil using a new --ima-sb-enable option [3]. >>>> This gives the downstream Linux distro the capability to offer the >>>> IMA architecture specific Secure Boot policy option, while giving >>>> the end-user the ability to decide if they want to use it. >>>> >>>> I have included links to both the mokutil [3] and shim [4] changes I >>>> made to support this new functionality. >>>> >>>> Thank you and looking forward to hearing your reviews. >>> >>> This patch set addresses two very different issues - allowing keys on >>> the platform keyring to be trusted for things other than verifying the >>> kexec kernel image signature, overwriting the arch specific IMA secure >>> boot policy rules. The only common denominator is basing those >>> decisions on UEFI variables, which has been previously suggested and >>> rejected. The threat model hasn't changed. >> >> Could you point me please to the previous discussion on the threat model >> this change would violate? What I found was [1], which I have tried to >> solve with this series. Having the ability to update a MOK variable >> indicates the user is not only root, but also the machine owner. MOK >> variable updates require both root access to update and then physical >> presence to set via shim after reboot. This patch set tries to address >> the "*second* order" Linus requested [2]. > > The concern is not with the normal way of updating MOK. > >> >>> The desire for allowing a single local CA key to be loaded onto a >>> trusted keyring is understandable. A local CA key can be used to sign >>> certificates, allowing them to be loaded onto the IMA keyring. What is >>> the need for multiple keys? >> >> We have no control over how many keys an end-user may wish to enroll. >> They might want to enroll a CA for IMA and a different key for their >> kernel modules. This is a generic kernel that can serve many different >> purposes. Think distro kernels - like Fedora, Ubuntu, Oracle Linux, etc. > > This patch set changes the secondary keyring root of trust, which is > currently the builtin or other keys on the secondary keyring. My > concern with this change, is that any key on the secondary keyring may > then be directly loaded or used to verify other keys being loaded onto > the IMA keyring. I understand the concern, that is why I left it up to the machine owner to decide what they want to trust. I took a quick look at a few other distros, each one I checked (Red Hat, CentOS, Fedora, Ubuntu) all carry this rejected patch [1]. These distributions have made the decision for the end-user that they will trust platform keys for verifying kernel modules. With my change, it defaults to what the upstream maintainers feel is an important trust model, but allows the end-user (assuming they are the machine owner too) to override it. This leaves the kernel distributer out of the picture. > I really do understand the need for extending the root of trust beyond > the builtin keys and allowing end user keys to be loaded onto a kernel > keyring, but it needs to be done safely. The first step might include > locally signing the MOK keys being loaded onto the secondary keyring > and then somehow safely providing the local-CA key id to the kernel. If the machine owner and Linux distributor are independent of one another, I don’t see how MOK key signing could work. There wouldn’t be a way for the kernel to verify the end-user supplied signed MOK key. An end-user choosing a Linux distro is trusting the company/organization building the kernel, but the trust doesn’t go the other way. Do you have a solution in mind on how this would be possible? If you do, I’m happy to move in a different direction to solve this problem. >>> Making an exception for using a UEFI key for anything other than >>> verifying the kexec kernel image, can not be based solely on UEFI >>> variables, but should require some form of kernel >>> agreement/confirmation. >> >> Isn’t that the case today with how MOK variables get set through >> mokutil and shim? >> >>> If/when a safe mechanism for identifying a >>> single local CA key is defined, the certificate should be loaded >>> directly onto the secondary keyring, not linked to the platform >>> keyring. >>> The system owner can enable/disable secure boot. Disabling the arch >>> secure boot IMA policy rules is not needed. However, another mechanism >>> for enabling them would be acceptable. >> >> For a distro kernel, disabling the arch secure boot IMA policy rules is >> needed. Distributions build a single kernel that can be used in many >> different ways. If we wanted to add a built-in IMA policy for an extra >> level of security protection, this allows the end-user to opt-in when >> secure boot is enabled. They are then protected before init is called. >> Not every user will want this protection; a different user may just want >> secure boot enabled without the IMA level protection. > > When secure boot is enabled, the IMA arch policy rules verify the kexec > kernel image is properly signed. When CONFIG_MODULE_SIG is not > configured, it also verifies kernel modules are properly signed. > >> After going through the mailing list history related to IMA appraisal, >> is this feature strictly geared towards a custom kernel used for a >> specific purpose? Do you view it as not being a feature suitable for >> a generic distribution kernel to offer? > > IMA-appraisal is enabled by distros, but requires labeling the > filesystem with security.ima xattrs, before loading an appraisal > policy. I was referring to digital signature based IMA-appraisal. If a company wanted to ship a distro where all immutable files are IMA signed, today it would not be feasible. The end-user will undoubtably want to install their own application, but this is not possible. The end-user can not IMA sign anything since they do not have the ability to add their own IMA CA. [1] https://lore.kernel.org/lkml/1556116431-7129-1-git-send-email-robeholmes@gmail.com/
[Cc'ing Patrick Uiterwijk] On Thu, 2021-05-20 at 14:37 -0600, Eric Snowberg wrote: > > On May 20, 2021, at 6:22 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: > > I really do understand the need for extending the root of trust beyond > > the builtin keys and allowing end user keys to be loaded onto a kernel > > keyring, but it needs to be done safely. The first step might include > > locally signing the MOK keys being loaded onto the secondary keyring > > and then somehow safely providing the local-CA key id to the kernel. > > If the machine owner and Linux distributor are independent of one another, > I don’t see how MOK key signing could work. There wouldn’t be a way for > the kernel to verify the end-user supplied signed MOK key. An end-user > choosing a Linux distro is trusting the company/organization building the > kernel, but the trust doesn’t go the other way. Do you have a solution > in mind on how this would be possible? If you do, I’m happy to move in > a different direction to solve this problem. We are working with the distros to address this problem. The first attempt at extending the secondary keyring's root of trust relied on a TPM2 NV Index[1]. Using MOK is a possible alternative, if it can be done safely. For example, if the boot command line could be protected from modification, the end-user could enroll a key in MOK and identify the specific MOK key on the boot command line[2]. The boot command line would then become an additional root of trust source. The root of trust for loading keys on the different trusted keyrings are self documenting - restrict_link_by_builtin_trusted, restrict_link_by_builtin_and_secondary_trusted(). A new function would need to be defined to include the boot command line as a new or additional root of trust source. thanks, Mimi [1] https://lore.kernel.org/linux-integrity/20210225203229.363302-1-patrick@puiterwijk.org/ [2] Perhaps extend the existing "ca_keys" boot command line option.
> On May 21, 2021, at 5:44 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: > > On Thu, 2021-05-20 at 14:37 -0600, Eric Snowberg wrote: >>> On May 20, 2021, at 6:22 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: > >>> I really do understand the need for extending the root of trust beyond >>> the builtin keys and allowing end user keys to be loaded onto a kernel >>> keyring, but it needs to be done safely. The first step might include >>> locally signing the MOK keys being loaded onto the secondary keyring >>> and then somehow safely providing the local-CA key id to the kernel. >> >> If the machine owner and Linux distributor are independent of one another, >> I don’t see how MOK key signing could work. There wouldn’t be a way for >> the kernel to verify the end-user supplied signed MOK key. An end-user >> choosing a Linux distro is trusting the company/organization building the >> kernel, but the trust doesn’t go the other way. Do you have a solution >> in mind on how this would be possible? If you do, I’m happy to move in >> a different direction to solve this problem. > > We are working with the distros to address this problem. The first > attempt at extending the secondary keyring's root of trust relied on a > TPM2 NV Index[1]. Yes, I saw that patch. I view (which could be a mistake on my part) digital signature based IMA appraisal as an extension of a verified boot. Once a TPM is introduced, it is an extension of a measured boot. It seems like this patch is using measured boot to solve a problem that exists on the verified boot side. While it may be a good solution for someone using both measured boot and verified boot at the same time, not all machines or VMs contain a TPM. > Using MOK is a possible alternative, if it can be done safely. I do want to point out, in case this was missed, when the new MOK variable is set to trust the platform keyring, PCR14 gets extended [1]. The UEFI BS var MokTPKState is mirrored to a freshly created UEFI RT var called MokTrustPlatform. The contents are extended into PCR14. This happens every time the system boots. The UEFI RT var does not persist across reboots, it is alway recreated by shim. The same thing happens with keys in the MOKList. Since the contents are mirrored, a key change can be detected on each boot. This makes it possible to use attestation to see if the system was booted with the proper variables set. For someone using measured boot, would this satisfy the requirement of safely protecting the system from a MOK update? > For example, if the boot command line could be protected from modification, > the end-user could enroll a key in MOK and identify the specific MOK > key on the boot command line[2]. The boot command line would then > become an additional root of trust source. > > The root of trust for loading keys on the different trusted keyrings > are self documenting - restrict_link_by_builtin_trusted, > restrict_link_by_builtin_and_secondary_trusted(). A new function would > need to be defined to include the boot command line as a new or > additional root of trust source. [1] https://github.com/esnowberg/shim/commit/ee3961b503e7d39cae7412ddf4e8d6709d998e87#diff-b1dd148baf92edaddd15cc8cd768201114ed86d991502bc492a827c66bbffb69R259
On Thu, May 20, 2021 at 02:37:31PM -0600, Eric Snowberg wrote: Good morning, I hope the week is starting well for everyone. > > On May 19, 2021, at 8:32 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: > > > >> After going through the mailing list history related to IMA appraisal, > >> is this feature strictly geared towards a custom kernel used for a > >> specific purpose? Do you view it as not being a feature suitable for > >> a generic distribution kernel to offer? > > > > IMA-appraisal is enabled by distros, but requires labeling the > > filesystem with security.ima xattrs, before loading an appraisal > > policy. > I was referring to digital signature based IMA-appraisal. If a > company wanted to ship a distro where all immutable files are IMA > signed, today it would not be feasible. The end-user will > undoubtably want to install their own application, but this is not > possible. The end-user can not IMA sign anything since they do not > have the ability to add their own IMA CA. I've spent 6+ years working on this issue, with a focus on trusted endpoint devices and their communications with trusted cloud endpoints. The challenge to trusted systems is that they not only have to be secure, they have to be tractable for the general development community to easily target, that is currently not the case. Eric, as you note, this extends to the notion of generic Linux distributions being able to deliver this tractability and flexibility to their user communities. Making this happen requires a much more generic system for modeling security behavior then what currently exists. If one looks at how security co-processors are going to evolve, this modeling will end up going out of the kernel into external devices, which are not going to be generic TPM's [*]. We have such an architecture for the 5.4 kernel, that with a little luck, we hope to be able to release by mid-summer. It peacefully co-exists with all of the existing integrity infrastructure which would make it tractable for a value add patch. It includes a namespace implementation for the security event modeling, without which, tractable trusted system development is a non-starter. If you are interested I will keep you in the loop. Have a good day. Greg [*] We've used SGX enclaves and ST based micro-controller implementations. As always, Dr. Greg Wettstein, Ph.D, Worker Autonomously self-defensive Enjellic Systems Development, LLC IOT platforms and edge devices. 4206 N. 19th Ave. Fargo, ND 58102 PH: 701-281-1686 EMAIL: greg@enjellic.com ------------------------------------------------------------------------------ "The vast majority of human beings dislike and even dread all notions with which they are not familiar. Hence it comes about that at their first appearance innovators have always been derided as fools and madmen." -- Aldous Huxley
On Sun, 2021-05-23 at 18:57 -0600, Eric Snowberg wrote: > > On May 21, 2021, at 5:44 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: > > > > On Thu, 2021-05-20 at 14:37 -0600, Eric Snowberg wrote: > >>> On May 20, 2021, at 6:22 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: > > > >>> I really do understand the need for extending the root of trust beyond > >>> the builtin keys and allowing end user keys to be loaded onto a kernel > >>> keyring, but it needs to be done safely. The first step might include > >>> locally signing the MOK keys being loaded onto the secondary keyring > >>> and then somehow safely providing the local-CA key id to the kernel. > >> > >> If the machine owner and Linux distributor are independent of one another, > >> I don’t see how MOK key signing could work. There wouldn’t be a way for > >> the kernel to verify the end-user supplied signed MOK key. An end-user > >> choosing a Linux distro is trusting the company/organization building the > >> kernel, but the trust doesn’t go the other way. Do you have a solution > >> in mind on how this would be possible? If you do, I’m happy to move in > >> a different direction to solve this problem. > > > > We are working with the distros to address this problem. The first > > attempt at extending the secondary keyring's root of trust relied on a > > TPM2 NV Index[1]. > > Yes, I saw that patch. I view (which could be a mistake on my part) > digital signature based IMA appraisal as an extension of a verified boot. > Once a TPM is introduced, it is an extension of a measured boot. It seems > like this patch is using measured boot to solve a problem that exists on > the verified boot side. While it may be a good solution for someone using > both measured boot and verified boot at the same time, not all machines or > VMs contain a TPM. True, the TPM is used as part of measured boot, but that doesn't prevent it from being used in other capacities. In this case the TPM2 NV Index was used just to store a public key and safely used based on TPM 2.0 rules. > > > Using MOK is a possible alternative, if it can be done safely. > > I do want to point out, in case this was missed, when the new MOK variable > is set to trust the platform keyring, PCR14 gets extended [1]. The UEFI BS > var MokTPKState is mirrored to a freshly created UEFI RT var called > MokTrustPlatform. The contents are extended into PCR14. This happens every > time the system boots. The UEFI RT var does not persist across reboots, it > is alway recreated by shim. The same thing happens with keys in the MOKList. > Since the contents are mirrored, a key change can be detected on each boot. > This makes it possible to use attestation to see if the system was booted > with the proper variables set. For someone using measured boot, would this > satisfy the requirement of safely protecting the system from a MOK update? TPM based trusted keys can be sealed to a TPM PCR. Only if the PCRs matched, is the private key unsealed. In that case, measuring provides the trust for releasing the private key. In this case, just measuring the UEFI MOK variable and key does not prevent an unknown public key from being loaded onto a keyring. Once loaded it could be used to verify any signed code's signature. Mimi > > For example, if the boot command line could be protected from modification, > > the end-user could enroll a key in MOK and identify the specific MOK > > key on the boot command line[2]. The boot command line would then > > become an additional root of trust source. > > > > The root of trust for loading keys on the different trusted keyrings > > are self documenting - restrict_link_by_builtin_trusted, > > restrict_link_by_builtin_and_secondary_trusted(). A new function would > > need to be defined to include the boot command line as a new or > > additional root of trust source. > > > [1] https://github.com/esnowberg/shim/commit/ee3961b503e7d39cae7412ddf4e8d6709d998e87#diff-b1dd148baf92edaddd15cc8cd768201114ed86d991502bc492a827c66bbffb69R259 >
> On May 24, 2021, at 5:12 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: > > On Sun, 2021-05-23 at 18:57 -0600, Eric Snowberg wrote: >>> On May 21, 2021, at 5:44 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: >>> >>> On Thu, 2021-05-20 at 14:37 -0600, Eric Snowberg wrote: >>>>> On May 20, 2021, at 6:22 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: >>> >>>>> I really do understand the need for extending the root of trust beyond >>>>> the builtin keys and allowing end user keys to be loaded onto a kernel >>>>> keyring, but it needs to be done safely. The first step might include >>>>> locally signing the MOK keys being loaded onto the secondary keyring >>>>> and then somehow safely providing the local-CA key id to the kernel. >>>> >>>> If the machine owner and Linux distributor are independent of one another, >>>> I don’t see how MOK key signing could work. There wouldn’t be a way for >>>> the kernel to verify the end-user supplied signed MOK key. An end-user >>>> choosing a Linux distro is trusting the company/organization building the >>>> kernel, but the trust doesn’t go the other way. Do you have a solution >>>> in mind on how this would be possible? If you do, I’m happy to move in >>>> a different direction to solve this problem. >>> >>> We are working with the distros to address this problem. The first >>> attempt at extending the secondary keyring's root of trust relied on a >>> TPM2 NV Index[1]. >> >> Yes, I saw that patch. I view (which could be a mistake on my part) >> digital signature based IMA appraisal as an extension of a verified boot. >> Once a TPM is introduced, it is an extension of a measured boot. It seems >> like this patch is using measured boot to solve a problem that exists on >> the verified boot side. While it may be a good solution for someone using >> both measured boot and verified boot at the same time, not all machines or >> VMs contain a TPM. > > True, the TPM is used as part of measured boot, but that doesn't > prevent it from being used in other capacities. In this case the TPM2 > NV Index was used just to store a public key and safely used based on > TPM 2.0 rules. > >> >>> Using MOK is a possible alternative, if it can be done safely. >> >> I do want to point out, in case this was missed, when the new MOK variable >> is set to trust the platform keyring, PCR14 gets extended [1]. The UEFI BS >> var MokTPKState is mirrored to a freshly created UEFI RT var called >> MokTrustPlatform. The contents are extended into PCR14. This happens every >> time the system boots. The UEFI RT var does not persist across reboots, it >> is alway recreated by shim. The same thing happens with keys in the MOKList. >> Since the contents are mirrored, a key change can be detected on each boot. >> This makes it possible to use attestation to see if the system was booted >> with the proper variables set. For someone using measured boot, would this >> satisfy the requirement of safely protecting the system from a MOK update? > > TPM based trusted keys can be sealed to a TPM PCR. Only if the PCRs > matched, is the private key unsealed. In that case, measuring > provides the trust for releasing the private key. In this case, just > measuring the UEFI MOK variable and key does not prevent an unknown > public key from being loaded onto a keyring. Once loaded it could be > used to verify any signed code's signature. Correct, it does not prevent an unknown public key from being loaded into a keyring. Shim prevents unknown public keys from being added. Only the machine owner with physical presence can make these changes. All keys shim loads into the MOKList get measured on each boot. If an unknown public key could be loaded into MOK, shim could boot any kernel signed with it as well. This kernel could be changed to load anything into the kernel keyring. So, I struggle to understand the difference; isn’t this exactly the same threat? If an end-user wanted to protect against either case, they would need to construct a measured boot attestation policy that included PCR14 and took the host out of service if the PCR values didn’t match up. >>> For example, if the boot command line could be protected from modification, >>> the end-user could enroll a key in MOK and identify the specific MOK >>> key on the boot command line[2]. The boot command line would then >>> become an additional root of trust source. >>> >>> The root of trust for loading keys on the different trusted keyrings >>> are self documenting - restrict_link_by_builtin_trusted, >>> restrict_link_by_builtin_and_secondary_trusted(). A new function would >>> need to be defined to include the boot command line as a new or >>> additional root of trust source. >> >> >> [1] https://github.com/esnowberg/shim/commit/ee3961b503e7d39cae7412ddf4e8d6709d998e87#diff-b1dd148baf92edaddd15cc8cd768201114ed86d991502bc492a827c66bbffb69R259