> On Sep 9, 2021, at 9:19 AM, Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > On Tue, 2021-09-07 at 12:00 -0400, Eric Snowberg wrote: >> Many UEFI Linux distributions boot using shim. The UEFI shim provides >> what is called Machine Owner Keys (MOK). Shim uses both the UEFI Secure >> Boot DB and MOK keys to validate the next step in the boot chain. The >> MOK facility can be used to import user generated keys. These keys can >> be used to sign an end-users development kernel build. When Linux >> boots, both UEFI Secure Boot DB and MOK keys get loaded in the Linux >> .platform keyring. >> >> Add a new Linux keyring called machine. This keyring shall contain just > > ^Define I’ll change this in the next round. > >> MOK CA keys and not the remaining keys in the platform keyring. This new >> machine keyring will be used in follow on patches. Unlike keys in the >> platform keyring, keys contained in the machine keyring will be trusted >> within the kernel if the end-user has chosen to do so. >> >> Signed-off-by: Eric Snowberg <eric.snowberg@xxxxxxxxxx> >> --- >> v1: Initial version >> v2: Removed destory keyring code >> v3: Unmodified from v2 >> v4: Add Kconfig, merged in "integrity: add add_to_mok_keyring" >> v5: Rename to machine keyring >> --- >> security/integrity/Kconfig | 11 +++++ >> security/integrity/Makefile | 1 + >> security/integrity/digsig.c | 1 + >> security/integrity/integrity.h | 12 +++++- >> .../platform_certs/machine_keyring.c | 42 +++++++++++++++++++ >> 5 files changed, 66 insertions(+), 1 deletion(-) >> create mode 100644 security/integrity/platform_certs/machine_keyring.c >> >> diff --git a/security/integrity/Kconfig b/security/integrity/Kconfig >> index 71f0177e8716..52193b86768a 100644 >> --- a/security/integrity/Kconfig >> +++ b/security/integrity/Kconfig >> @@ -62,6 +62,17 @@ config INTEGRITY_PLATFORM_KEYRING >> provided by the platform for verifying the kexec'ed kerned image >> and, possibly, the initramfs signature. >> >> +config INTEGRITY_MACHINE_KEYRING >> + bool "Provide a keyring to which CA Machine Owner Keys may be added" >> + depends on SECONDARY_TRUSTED_KEYRING >> + depends on INTEGRITY_ASYMMETRIC_KEYS >> + depends on SYSTEM_BLACKLIST_KEYRING >> + help >> + If set, provide a keyring to which CA Machine Owner Keys (MOK) may >> + be added. This keyring shall contain just CA MOK keys. Unlike keys >> + in the platform keyring, keys contained in the .machine keyring will >> + be trusted within the kernel. > > No sense in creating the ".machine" keyring, unless it is possible to > safely load CA certificates on it. At least for the time being, this > should also be dependent on EFI. > Will also add a depends for EFI >> +++ b/security/integrity/platform_certs/machine_keyring.c >> @@ -0,0 +1,42 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* >> + * Machine keyring routines. >> + * >> + * Copyright (c) 2021, Oracle and/or its affiliates. >> + */ >> + >> +#include "../integrity.h" >> + >> +static __init int machine_keyring_init(void) >> +{ >> + int rc; >> + >> + rc = integrity_init_keyring(INTEGRITY_KEYRING_MACHINE); >> + if (rc) >> + return rc; >> + >> + pr_notice("Machine keyring initialized\n"); >> + return 0; >> +} >> +device_initcall(machine_keyring_init); >> + >> +void __init add_to_machine_keyring(const char *source, const void *data, size_t len) >> +{ >> + key_perm_t perm; >> + int rc; >> + >> + perm = (KEY_POS_ALL & ~KEY_POS_SETATTR) | KEY_USR_VIEW; >> + rc = integrity_load_cert(INTEGRITY_KEYRING_MACHINE, source, data, len, perm); >> + >> + /* >> + * Some MOKList keys may not pass the machine keyring restrictions. >> + * If the restriction check does not pass and the platform keyring >> + * is configured, try to add it into that keyring instead. >> + */ >> + if (rc) > > In addition to the comment, also test to see if the ".platform" keyring > is configured. and will add this too. Thanks.