| Message ID | 20211116001545.2639333-1-eric.snowberg@oracle.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Enroll kernel keys thru MOK | expand |
On Mon, 2021-11-15 at 19:15 -0500, Eric Snowberg wrote: > Back in 2013 Linus requested a feature to allow end-users to have the > ability "to add their own keys and sign modules they trust". This was > his *second* order outlined here [1]. There have been many attempts > over the years to solve this problem, all have been rejected. Many > of the failed attempts loaded all preboot firmware keys into the kernel, > including the Secure Boot keys. Many distributions carry one of these > rejected attempts [2], [3], [4]. This series tries to solve this problem > with a solution that takes into account all the problems brought up in > the previous attempts. > > On UEFI based systems, this series introduces a new Linux kernel keyring > containing the Machine Owner Keys (MOK) called machine. It also defines > a new MOK variable in shim. This variable allows the end-user to decide > if they want to load MOK keys into the machine keyring. Mimi has suggested > that only CA keys contained within the MOK be loaded into the machine > keyring. All other certs will load into the platform keyring instead. > > By default, nothing changes; MOK keys are not loaded into the machine > keyring. They are only loaded after the end-user makes the decision > themselves. The end-user would set this through mokutil using a new > --trust-mok option [5]. This would work similar to how the kernel uses > MOK variables to enable/disable signature validation as well as use/ignore > the db. Any kernel operation that uses either the builtin or secondary > trusted keys as a trust source shall also reference the new machine > keyring as a trust source. > > Secure Boot keys will never be loaded into the machine keyring. They > will always be loaded into the platform keyring. If an end-user wanted > to load one, they would need to enroll it into the MOK. > > Steps required by the end user: > > Sign kernel module with user created key: > $ /usr/src/kernels/$(uname -r)/scripts/sign-file sha512 \ > machine_signing_key.priv machine_signing_key.x509 my_module.ko > > Import the key into the MOK > $ mokutil --import machine_signing_key.x509 > > Setup the kernel to load MOK keys into the .machine keyring > $ mokutil --trust-mok > > Then reboot, the MokManager will load and ask if you want to trust the > MOK key and enroll the MOK into the MOKList. Afterwards the signed kernel > module will load. > > I have included a link to the mokutil [5] changes I have made to support > this new functionality. The shim changes have now been accepted > upstream [6]. > > [1] https://marc.info/?l=linux-kernel&m=136185386310140&w=2 > [2] https://lore.kernel.org/lkml/1479737095.2487.34.camel@linux.vnet.ibm.com/ > [3] https://lore.kernel.org/lkml/1556221605.24945.3.camel@HansenPartnership.com/ > [4] https://lore.kernel.org/linux-integrity/1e41f22b1f11784f1e943f32bf62034d4e054cdb.camel@HansenPartnership.com/ > [5] https://github.com/esnowberg/mokutil/tree/mokvars-v3 > [6] https://github.com/rhboot/shim/commit/4e513405b4f1641710115780d19dcec130c5208f > > Eric Snowberg (17): > integrity: Introduce a Linux keyring called machine > integrity: Do not allow machine keyring updates following init > KEYS: Create static version of public_key_verify_signature > X.509: Parse Basic Constraints for CA > KEYS: CA link restriction > integrity: restrict INTEGRITY_KEYRING_MACHINE to restrict_link_by_ca > integrity: Fix warning about missing prototypes > integrity: add new keyring handler for mok keys > KEYS: Rename get_builtin_and_secondary_restriction > KEYS: add a reference to machine keyring > KEYS: Introduce link restriction for machine keys > KEYS: integrity: change link restriction to trust the machine keyring > KEYS: link secondary_trusted_keys to machine trusted keys > integrity: store reference to machine keyring > efi/mokvar: move up init order > integrity: Trust MOK keys if MokListTrustedRT found > integrity: Only use machine keyring when uefi_check_trust_mok_keys is > true > > certs/system_keyring.c | 44 ++++++++++- > crypto/asymmetric_keys/restrict.c | 43 +++++++++++ > crypto/asymmetric_keys/x509_cert_parser.c | 9 +++ > drivers/firmware/efi/mokvar-table.c | 2 +- > include/crypto/public_key.h | 15 ++++ > include/keys/system_keyring.h | 14 ++++ > security/integrity/Kconfig | 12 +++ > security/integrity/Makefile | 1 + > security/integrity/digsig.c | 23 +++++- > security/integrity/integrity.h | 17 +++- > .../platform_certs/keyring_handler.c | 18 ++++- > .../platform_certs/keyring_handler.h | 5 ++ > security/integrity/platform_certs/load_uefi.c | 4 +- > .../platform_certs/machine_keyring.c | 77 +++++++++++++++++++ > 14 files changed, 273 insertions(+), 11 deletions(-) > create mode 100644 security/integrity/platform_certs/machine_keyring.c > > > base-commit: fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf Does shim have the necessary features in a release? /Jarkko
> > I have included a link to the mokutil [5] changes I have made to support > > this new functionality. The shim changes have now been accepted > > upstream [6]. ..snip.. > > [6] https://github.com/rhboot/shim/commit/4e513405b4f1641710115780d19dcec130c5208f ..snip.. > > Does shim have the necessary features in a release? Hi! It has been accepted in the upstream shim. If you are looking for a distribution having rolled out a shim with this feature (so signed by MSF) I fear that distributions are not that fast with shim releases. Also these: https://github.com/rhboot/shim/pulls https://github.com/rhboot/shim/issues do mean some extra work would need to go in before an official release is cut. Hope this helps?
On Tue, 2021-11-16 at 11:18 -0500, Konrad Rzeszutek Wilk wrote: > > > I have included a link to the mokutil [5] changes I have made to support > > > this new functionality. The shim changes have now been accepted > > > upstream [6]. > > ..snip.. > > > [6] https://github.com/rhboot/shim/commit/4e513405b4f1641710115780d19dcec130c5208f > > ..snip.. > > > > Does shim have the necessary features in a release? > > Hi! > > It has been accepted in the upstream shim. If you are looking > for a distribution having rolled out a shim with this feature (so signed > by MSF) I fear that distributions are not that fast with shim releases. > > Also these: > https://github.com/rhboot/shim/pulls > https://github.com/rhboot/shim/issues > > do mean some extra work would need to go in before an official > release is cut. > > Hope this helps? Yes. I'll hold with this up until there is an official release. Thank you. /Jarkko
On Tue, Nov 16, 2021 at 06:24:52PM +0200, Jarkko Sakkinen wrote: > On Tue, 2021-11-16 at 11:18 -0500, Konrad Rzeszutek Wilk wrote: > > > > I have included a link to the mokutil [5] changes I have made to support > > > > this new functionality. The shim changes have now been accepted > > > > upstream [6]. > > > > ..snip.. > > > > [6] https://github.com/rhboot/shim/commit/4e513405b4f1641710115780d19dcec130c5208f > > > > ..snip.. > > > > > > Does shim have the necessary features in a release? > > > > Hi! > > > > It has been accepted in the upstream shim. If you are looking > > for a distribution having rolled out a shim with this feature (so signed > > by MSF) I fear that distributions are not that fast with shim releases. > > > > Also these: > > https://github.com/rhboot/shim/pulls > > https://github.com/rhboot/shim/issues > > > > do mean some extra work would need to go in before an official > > release is cut. > > > > Hope this helps? > > Yes. I'll hold with this up until there is an official release. Thank you. Not sure I understand - but what are the concerns you have with shim code that has been accepted?
On Tue, 2021-11-16 at 11:39 -0500, Konrad Rzeszutek Wilk wrote: > On Tue, Nov 16, 2021 at 06:24:52PM +0200, Jarkko Sakkinen wrote: > > On Tue, 2021-11-16 at 11:18 -0500, Konrad Rzeszutek Wilk wrote: > > > > > I have included a link to the mokutil [5] changes I have made to support > > > > > this new functionality. The shim changes have now been accepted > > > > > upstream [6]. > > > > > > ..snip.. > > > > > [6] https://github.com/rhboot/shim/commit/4e513405b4f1641710115780d19dcec130c5208f > > > > > > ..snip.. > > > > > > > > Does shim have the necessary features in a release? > > > > > > Hi! > > > > > > It has been accepted in the upstream shim. If you are looking > > > for a distribution having rolled out a shim with this feature (so signed > > > by MSF) I fear that distributions are not that fast with shim releases. ~~~ Should that be MS, or what does MSF mean? > > > > > > Also these: > > > https://github.com/rhboot/shim/pulls > > > https://github.com/rhboot/shim/issues > > > > > > do mean some extra work would need to go in before an official > > > release is cut. > > > > > > Hope this helps? > > > > Yes. I'll hold with this up until there is an official release. Thank you. > > Not sure I understand - but what are the concerns you have with shim > code that has been accepted? Maybe my concern is that none of the patches have a tested-by? Probably would be easier to get a test coverage, e.g. for people like me who do not even know how to self-compile Shim, how to setup user space using the product and so forth. I don't demand a release, if the changes have been accepted, but 17 patches do need to be tested. /Jarkko
On Wed, 2021-11-17 at 09:50 +0200, Jarkko Sakkinen wrote: > On Tue, 2021-11-16 at 11:39 -0500, Konrad Rzeszutek Wilk wrote: > > On Tue, Nov 16, 2021 at 06:24:52PM +0200, Jarkko Sakkinen wrote: > > > On Tue, 2021-11-16 at 11:18 -0500, Konrad Rzeszutek Wilk wrote: > > > > > > I have included a link to the mokutil [5] changes I have made to support > > > > > > this new functionality. The shim changes have now been accepted > > > > > > upstream [6]. > > > > > > > > ..snip.. > > > > > > [6] https://github.com/rhboot/shim/commit/4e513405b4f1641710115780d19dcec130c5208f > > > > > > > > ..snip.. > > > > > > > > > > Does shim have the necessary features in a release? > > > > > > > > Hi! > > > > > > > > It has been accepted in the upstream shim. If you are looking > > > > for a distribution having rolled out a shim with this feature (so signed > > > > by MSF) I fear that distributions are not that fast with shim releases. > ~~~ > > Should that be MS, or what does MSF mean? > > > > > > > > > Also these: > > > > https://github.com/rhboot/shim/pulls > > > > https://github.com/rhboot/shim/issues > > > > > > > > do mean some extra work would need to go in before an official > > > > release is cut. > > > > > > > > Hope this helps? > > > > > > Yes. I'll hold with this up until there is an official release. Thank you. > > > > Not sure I understand - but what are the concerns you have with shim > > code that has been accepted? > > Maybe my concern is that none of the patches have a tested-by? > > Probably would be easier to get a test coverage, e.g. for people like > me who do not even know how to self-compile Shim, how to setup user > space using the product and so forth. ~~~~~~~~~~~~~~~~~ for the end product /Jarkko
On Wed, Nov 17, 2021 at 09:51:25AM +0200, Jarkko Sakkinen wrote: > On Wed, 2021-11-17 at 09:50 +0200, Jarkko Sakkinen wrote: > > On Tue, 2021-11-16 at 11:39 -0500, Konrad Rzeszutek Wilk wrote: > > > On Tue, Nov 16, 2021 at 06:24:52PM +0200, Jarkko Sakkinen wrote: > > > > On Tue, 2021-11-16 at 11:18 -0500, Konrad Rzeszutek Wilk wrote: > > > > > > > I have included a link to the mokutil [5] changes I have made to support > > > > > > > this new functionality. The shim changes have now been accepted > > > > > > > upstream [6]. > > > > > > > > > > ..snip.. > > > > > > > [6] https://github.com/rhboot/shim/commit/4e513405b4f1641710115780d19dcec130c5208f > > > > > > > > > > ..snip.. > > > > > > > > > > > > Does shim have the necessary features in a release? > > > > > > > > > > Hi! > > > > > > > > > > It has been accepted in the upstream shim. If you are looking > > > > > for a distribution having rolled out a shim with this feature (so signed > > > > > by MSF) I fear that distributions are not that fast with shim releases. > > ~~~ > > > > Should that be MS, or what does MSF mean? Microsoft :-) > > > > > > > > > > > > Also these: > > > > > https://github.com/rhboot/shim/pulls > > > > > https://github.com/rhboot/shim/issues > > > > > > > > > > do mean some extra work would need to go in before an official > > > > > release is cut. > > > > > > > > > > Hope this helps? > > > > > > > > Yes. I'll hold with this up until there is an official release. Thank you. > > > > > > Not sure I understand - but what are the concerns you have with shim > > > code that has been accepted? > > > > Maybe my concern is that none of the patches have a tested-by? > > > > Probably would be easier to get a test coverage, e.g. for people like > > me who do not even know how to self-compile Shim, how to setup user > > space using the product and so forth. > ~~~~~~~~~~~~~~~~~ > > for the end product <nods> That makes total sense. Thanks for the explanation, let me double check whether https://github.com/rhboot/shim/blob/main/BUILDING is still correct. > > /Jarkko > > >
> On Nov 17, 2021, at 10:02 AM, Konrad Wilk <konrad.wilk@oracle.com> wrote: > > On Wed, Nov 17, 2021 at 09:51:25AM +0200, Jarkko Sakkinen wrote: >> On Wed, 2021-11-17 at 09:50 +0200, Jarkko Sakkinen wrote: >>> On Tue, 2021-11-16 at 11:39 -0500, Konrad Rzeszutek Wilk wrote: >>>> On Tue, Nov 16, 2021 at 06:24:52PM +0200, Jarkko Sakkinen wrote: >>>>> On Tue, 2021-11-16 at 11:18 -0500, Konrad Rzeszutek Wilk wrote: >>>>>>>> I have included a link to the mokutil [5] changes I have made to support >>>>>>>> this new functionality. The shim changes have now been accepted >>>>>>>> upstream [6]. >>>>>> >>>>>> ..snip.. >>>>>>>> [6] https://github.com/rhboot/shim/commit/4e513405b4f1641710115780d19dcec130c5208f >>>>>> >>>>>> ..snip.. >>>>>>> >>>>>>> Does shim have the necessary features in a release? >>>>>> >>>>>> Hi! >>>>>> >>>>>> It has been accepted in the upstream shim. If you are looking >>>>>> for a distribution having rolled out a shim with this feature (so signed >>>>>> by MSF) I fear that distributions are not that fast with shim releases. >>> ~~~ >>> >>> Should that be MS, or what does MSF mean? > > Microsoft :-) Correct, I’ll fix that in the next round. >>>>>> >>>>>> Also these: >>>>>> https://github.com/rhboot/shim/pulls >>>>>> https://github.com/rhboot/shim/issues >>>>>> >>>>>> do mean some extra work would need to go in before an official >>>>>> release is cut. >>>>>> >>>>>> Hope this helps? >>>>> >>>>> Yes. I'll hold with this up until there is an official release. Thank you. >>>> >>>> Not sure I understand - but what are the concerns you have with shim >>>> code that has been accepted? >>> >>> Maybe my concern is that none of the patches have a tested-by? >>> >>> Probably would be easier to get a test coverage, e.g. for people like >>> me who do not even know how to self-compile Shim, how to setup user >>> space using the product and so forth. >> ~~~~~~~~~~~~~~~~~ >> >> for the end product > > <nods> That makes total sense. Thanks for the explanation, let me double > check whether > > https://github.com/rhboot/shim/blob/main/BUILDING > > is still correct. Those are the steps I use for building. I then move over mmx64.efi and shimx64.efi to the ESP. I can add the shim build/install instructions to the next cover letter If you think that would be appropriate.
On Wed, 2021-11-17 at 17:20 +0000, Eric Snowberg wrote: > > > > On Nov 17, 2021, at 10:02 AM, Konrad Wilk <konrad.wilk@oracle.com> wrote: > > > > On Wed, Nov 17, 2021 at 09:51:25AM +0200, Jarkko Sakkinen wrote: > > > On Wed, 2021-11-17 at 09:50 +0200, Jarkko Sakkinen wrote: > > > > On Tue, 2021-11-16 at 11:39 -0500, Konrad Rzeszutek Wilk wrote: > > > > > On Tue, Nov 16, 2021 at 06:24:52PM +0200, Jarkko Sakkinen wrote: > > > > > > On Tue, 2021-11-16 at 11:18 -0500, Konrad Rzeszutek Wilk wrote: > > > > > > > > > I have included a link to the mokutil [5] changes I have made to support > > > > > > > > > this new functionality. The shim changes have now been accepted > > > > > > > > > upstream [6]. > > > > > > > > > > > > > > ..snip.. > > > > > > > > > [6] https://github.com/rhboot/shim/commit/4e513405b4f1641710115780d19dcec130c5208f > > > > > > > > > > > > > > ..snip.. > > > > > > > > > > > > > > > > Does shim have the necessary features in a release? > > > > > > > > > > > > > > Hi! > > > > > > > > > > > > > > It has been accepted in the upstream shim. If you are looking > > > > > > > for a distribution having rolled out a shim with this feature (so signed > > > > > > > by MSF) I fear that distributions are not that fast with shim releases. > > > > ~~~ > > > > > > > > Should that be MS, or what does MSF mean? > > > > Microsoft :-) > > Correct, I’ll fix that in the next round. > > > > > > > > > > > > > > > Also these: > > > > > > > https://github.com/rhboot/shim/pulls > > > > > > > https://github.com/rhboot/shim/issues > > > > > > > > > > > > > > do mean some extra work would need to go in before an official > > > > > > > release is cut. > > > > > > > > > > > > > > Hope this helps? > > > > > > > > > > > > Yes. I'll hold with this up until there is an official release. Thank you. > > > > > > > > > > Not sure I understand - but what are the concerns you have with shim > > > > > code that has been accepted? > > > > > > > > Maybe my concern is that none of the patches have a tested-by? > > > > > > > > Probably would be easier to get a test coverage, e.g. for people like > > > > me who do not even know how to self-compile Shim, how to setup user > > > > space using the product and so forth. > > > ~~~~~~~~~~~~~~~~~ > > > > > > for the end product > > > > <nods> That makes total sense. Thanks for the explanation, let me double > > check whether > > > > https://github.com/rhboot/shim/blob/main/BUILDING > > > > is still correct. > > Those are the steps I use for building. I then move over mmx64.efi and > shimx64.efi to the ESP. I can add the shim build/install instructions to the next > cover letter If you think that would be appropriate. Yeah, that would be great. I'll try to setup VM for that purpose. I have already a script to build UEFI enabled archlinux VM's, which I use to test SGX patches. I can probably tailor that for this purpose. /Jarkko
Back in 2013 Linus requested a feature to allow end-users to have the ability "to add their own keys and sign modules they trust". This was his *second* order outlined here [1]. There have been many attempts over the years to solve this problem, all have been rejected. Many of the failed attempts loaded all preboot firmware keys into the kernel, including the Secure Boot keys. Many distributions carry one of these rejected attempts [2], [3], [4]. This series tries to solve this problem with a solution that takes into account all the problems brought up in the previous attempts. On UEFI based systems, this series introduces a new Linux kernel keyring containing the Machine Owner Keys (MOK) called machine. It also defines a new MOK variable in shim. This variable allows the end-user to decide if they want to load MOK keys into the machine keyring. Mimi has suggested that only CA keys contained within the MOK be loaded into the machine keyring. All other certs will load into the platform keyring instead. By default, nothing changes; MOK keys are not loaded into the machine keyring. They are only loaded after the end-user makes the decision themselves. The end-user would set this through mokutil using a new --trust-mok option [5]. This would work similar to how the kernel uses MOK variables to enable/disable signature validation as well as use/ignore the db. Any kernel operation that uses either the builtin or secondary trusted keys as a trust source shall also reference the new machine keyring as a trust source. Secure Boot keys will never be loaded into the machine keyring. They will always be loaded into the platform keyring. If an end-user wanted to load one, they would need to enroll it into the MOK. Steps required by the end user: Sign kernel module with user created key: $ /usr/src/kernels/$(uname -r)/scripts/sign-file sha512 \ machine_signing_key.priv machine_signing_key.x509 my_module.ko Import the key into the MOK $ mokutil --import machine_signing_key.x509 Setup the kernel to load MOK keys into the .machine keyring $ mokutil --trust-mok Then reboot, the MokManager will load and ask if you want to trust the MOK key and enroll the MOK into the MOKList. Afterwards the signed kernel module will load. I have included a link to the mokutil [5] changes I have made to support this new functionality. The shim changes have now been accepted upstream [6]. [1] https://marc.info/?l=linux-kernel&m=136185386310140&w=2 [2] https://lore.kernel.org/lkml/1479737095.2487.34.camel@linux.vnet.ibm.com/ [3] https://lore.kernel.org/lkml/1556221605.24945.3.camel@HansenPartnership.com/ [4] https://lore.kernel.org/linux-integrity/1e41f22b1f11784f1e943f32bf62034d4e054cdb.camel@HansenPartnership.com/ [5] https://github.com/esnowberg/mokutil/tree/mokvars-v3 [6] https://github.com/rhboot/shim/commit/4e513405b4f1641710115780d19dcec130c5208f Eric Snowberg (17): integrity: Introduce a Linux keyring called machine integrity: Do not allow machine keyring updates following init KEYS: Create static version of public_key_verify_signature X.509: Parse Basic Constraints for CA KEYS: CA link restriction integrity: restrict INTEGRITY_KEYRING_MACHINE to restrict_link_by_ca integrity: Fix warning about missing prototypes integrity: add new keyring handler for mok keys KEYS: Rename get_builtin_and_secondary_restriction KEYS: add a reference to machine keyring KEYS: Introduce link restriction for machine keys KEYS: integrity: change link restriction to trust the machine keyring KEYS: link secondary_trusted_keys to machine trusted keys integrity: store reference to machine keyring efi/mokvar: move up init order integrity: Trust MOK keys if MokListTrustedRT found integrity: Only use machine keyring when uefi_check_trust_mok_keys is true certs/system_keyring.c | 44 ++++++++++- crypto/asymmetric_keys/restrict.c | 43 +++++++++++ crypto/asymmetric_keys/x509_cert_parser.c | 9 +++ drivers/firmware/efi/mokvar-table.c | 2 +- include/crypto/public_key.h | 15 ++++ include/keys/system_keyring.h | 14 ++++ security/integrity/Kconfig | 12 +++ security/integrity/Makefile | 1 + security/integrity/digsig.c | 23 +++++- security/integrity/integrity.h | 17 +++- .../platform_certs/keyring_handler.c | 18 ++++- .../platform_certs/keyring_handler.h | 5 ++ security/integrity/platform_certs/load_uefi.c | 4 +- .../platform_certs/machine_keyring.c | 77 +++++++++++++++++++ 14 files changed, 273 insertions(+), 11 deletions(-) create mode 100644 security/integrity/platform_certs/machine_keyring.c base-commit: fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf