Message ID | 20241017155516.2582369-1-eric.snowberg@oracle.com |
---|---|
Headers | show |
Series | Clavis LSM | expand |
On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote: > Remove the CONFIG_INTEGRITY_PLATFORM_KEYRING ifdef check so this > pattern does not need to be repeated with new code. > > Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com> > --- > certs/system_keyring.c | 6 ------ > 1 file changed, 6 deletions(-) > > diff --git a/certs/system_keyring.c b/certs/system_keyring.c > index 9de610bf1f4b..e344cee10d28 100644 > --- a/certs/system_keyring.c > +++ b/certs/system_keyring.c > @@ -24,9 +24,7 @@ static struct key *secondary_trusted_keys; > #ifdef CONFIG_INTEGRITY_MACHINE_KEYRING > static struct key *machine_trusted_keys; > #endif > -#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING > static struct key *platform_trusted_keys; > -#endif > > extern __initconst const u8 system_certificate_list[]; > extern __initconst const unsigned long system_certificate_list_size; > @@ -345,11 +343,7 @@ int verify_pkcs7_message_sig(const void *data, > size_t len, > trusted_keys = builtin_trusted_keys; > #endif > } else if (trusted_keys == VERIFY_USE_PLATFORM_KEYRING) { > -#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING > trusted_keys = platform_trusted_keys; > -#else > - trusted_keys = NULL; > -#endif > if (!trusted_keys) { > ret = -ENOKEY; > pr_devel("PKCS#7 platform keyring is not > available\n"); Just to check with the argument that any commit should bring the Git tree to another "good state". Why this was flagged? What would be the collateral damage if only this commit was picked and put to a pull request? No intentions to do that, this more like forming a better understanding what is at stake here. I.e. I get that you need this for subsequent commits but I think the commit message should also have like explanation why this is a legit change otherwise. I mean, less flagging better if it does not cause harm is already great without higher level goals. BR, Jarkko
> On Oct 17, 2024, at 10:13 AM, Jarkko Sakkinen <jarkko@kernel.org> wrote: > > On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote: >> Remove the CONFIG_INTEGRITY_PLATFORM_KEYRING ifdef check so this >> pattern does not need to be repeated with new code. >> >> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com> >> --- >> certs/system_keyring.c | 6 ------ >> 1 file changed, 6 deletions(-) >> >> diff --git a/certs/system_keyring.c b/certs/system_keyring.c >> index 9de610bf1f4b..e344cee10d28 100644 >> --- a/certs/system_keyring.c >> +++ b/certs/system_keyring.c >> @@ -24,9 +24,7 @@ static struct key *secondary_trusted_keys; >> #ifdef CONFIG_INTEGRITY_MACHINE_KEYRING >> static struct key *machine_trusted_keys; >> #endif >> -#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING >> static struct key *platform_trusted_keys; >> -#endif >> >> extern __initconst const u8 system_certificate_list[]; >> extern __initconst const unsigned long system_certificate_list_size; >> @@ -345,11 +343,7 @@ int verify_pkcs7_message_sig(const void *data, >> size_t len, >> trusted_keys = builtin_trusted_keys; >> #endif >> } else if (trusted_keys == VERIFY_USE_PLATFORM_KEYRING) { >> -#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING >> trusted_keys = platform_trusted_keys; >> -#else >> - trusted_keys = NULL; >> -#endif >> if (!trusted_keys) { >> ret = -ENOKEY; >> pr_devel("PKCS#7 platform keyring is not >> available\n"); > > Just to check with the argument that any commit should bring the Git > tree to another "good state". Why this was flagged? What would be the > collateral damage if only this commit was picked and put to a pull > request? No intentions to do that, this more like forming a better > understanding what is at stake here. > > I.e. I get that you need this for subsequent commits but I think the > commit message should also have like explanation why this is a legit > change otherwise. Thanks for taking a look at this, I will add a better explanation in the next round.
On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote: > +static struct asymmetric_key_id *clavis_parse_boot_param(char *kid, > struct asymmetric_key_id *akid, > + int > akid_max_len) > +{ > + int error, hex_len; > + > + if (!kid) > + return 0; > + > + hex_len = strlen(kid) / 2; Hmmm... I'd consider sanity checking this: size_t len; /* ... */ len = strlen(kid); if (len % 2) { pr_err("Clavis key id has invalid length %lu\n", len); return 0; } hex_len = len / 2; BR, Jarkko
On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote: > Add a new verification type called VERIFYING_CLAVIS_SIGNATURE. This > new > usage will be used for validating keys added to the new clavis LSM > keyring. > This will be introduced in a follow-on patch. > > Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com> > --- > crypto/asymmetric_keys/asymmetric_type.c | 1 + > crypto/asymmetric_keys/pkcs7_verify.c | 1 + > include/linux/verification.h | 2 ++ > 3 files changed, 4 insertions(+) > > diff --git a/crypto/asymmetric_keys/asymmetric_type.c > b/crypto/asymmetric_keys/asymmetric_type.c > index 43af5fa510c0..d7bf95c77f4a 100644 > --- a/crypto/asymmetric_keys/asymmetric_type.c > +++ b/crypto/asymmetric_keys/asymmetric_type.c > @@ -25,6 +25,7 @@ const char *const > key_being_used_for[NR__KEY_BEING_USED_FOR] = { > [VERIFYING_KEY_SIGNATURE] = "key sig", > [VERIFYING_KEY_SELF_SIGNATURE] = "key self sig", > [VERIFYING_UNSPECIFIED_SIGNATURE] = "unspec sig", > + [VERIFYING_CLAVIS_SIGNATURE] = "clavis sig", > }; > EXPORT_SYMBOL_GPL(key_being_used_for); > > diff --git a/crypto/asymmetric_keys/pkcs7_verify.c > b/crypto/asymmetric_keys/pkcs7_verify.c > index f0d4ff3c20a8..1dc80e68ce96 100644 > --- a/crypto/asymmetric_keys/pkcs7_verify.c > +++ b/crypto/asymmetric_keys/pkcs7_verify.c > @@ -428,6 +428,7 @@ int pkcs7_verify(struct pkcs7_message *pkcs7, > } > /* Authattr presence checked in parser */ > break; > + case VERIFYING_CLAVIS_SIGNATURE: > case VERIFYING_UNSPECIFIED_SIGNATURE: > if (pkcs7->data_type != OID_data) { > pr_warn("Invalid unspecified sig (not pkcs7- > data)\n"); > diff --git a/include/linux/verification.h > b/include/linux/verification.h > index cb2d47f28091..02d2d70e2324 100644 > --- a/include/linux/verification.h > +++ b/include/linux/verification.h > @@ -36,6 +36,8 @@ enum key_being_used_for { > VERIFYING_KEY_SIGNATURE, > VERIFYING_KEY_SELF_SIGNATURE, > VERIFYING_UNSPECIFIED_SIGNATURE, > + /* Add new entries above, keep VERIFYING_CLAVIS_SIGNATURE at > the end. */ > + VERIFYING_CLAVIS_SIGNATURE, > NR__KEY_BEING_USED_FOR > }; > extern const char *const key_being_used_for[NR__KEY_BEING_USED_FOR]; This looks as good as it can get. Just wondering that does this Clavis thing connect with the TPM2 asymmetric keys that I've been working on? I.e. can they be used in tandem. I should really update that patch set (latest from April). BR, Jarkko
On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote: > If the kernel is built with CONFIG_MODULE_SIG_KEY, get the subject > key identifier and add an ACL for it within the .clavis keyring. > > Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com> Super sound splits! Nice to review, have to give credit on this :-) > --- > certs/.gitignore | 1 + > certs/Makefile | 20 ++++++++++++++++++++ > certs/clavis_module_acl.c | 7 +++++++ > security/clavis/clavis.h | 9 +++++++++ > security/clavis/clavis_keyring.c | 27 +++++++++++++++++++++++++++ > 5 files changed, 64 insertions(+) > create mode 100644 certs/clavis_module_acl.c > > diff --git a/certs/.gitignore b/certs/.gitignore > index cec5465f31c1..dc99ae5a2585 100644 > --- a/certs/.gitignore > +++ b/certs/.gitignore > @@ -3,3 +3,4 @@ > /extract-cert > /x509_certificate_list > /x509_revocation_list > +/module_acl > diff --git a/certs/Makefile b/certs/Makefile > index f6fa4d8d75e0..f2555e5296f5 100644 > --- a/certs/Makefile > +++ b/certs/Makefile > @@ -6,6 +6,7 @@ > obj-$(CONFIG_SYSTEM_TRUSTED_KEYRING) += system_keyring.o > system_certificates.o > obj-$(CONFIG_SYSTEM_BLACKLIST_KEYRING) += blacklist.o > blacklist_hashes.o > obj-$(CONFIG_SYSTEM_REVOCATION_LIST) += revocation_certificates.o > +obj-$(CONFIG_SECURITY_CLAVIS) += clavis_module_acl.o > > $(obj)/blacklist_hashes.o: $(obj)/blacklist_hash_list > CFLAGS_blacklist_hashes.o := -I $(obj) > @@ -75,6 +76,25 @@ $(obj)/signing_key.x509: $(filter-out > $(PKCS11_URI),$(CONFIG_MODULE_SIG_KEY)) $( > > targets += signing_key.x509 > > +ifeq ($(CONFIG_MODULE_SIG_KEY),) > +quiet_cmd_make_module_acl = GEN $@ > + cmd_make_module_acl = \ > + echo > $@ > +else > +quiet_cmd_make_module_acl = GEN $@ > + cmd_make_module_acl = \ > + openssl x509 -in $< -inform der -ext subjectKeyIdentifier - > nocert | \ > + tail -n +2 | cut -f2 -d '='| tr -d ':' | tr '[:upper:]' > '[:lower:]' | \ > + sed 's/^[ \t]*//; s/.*/"00:&",/' > $@ > +endif > + > +$(obj)/module_acl: $(obj)/signing_key.x509 FORCE > + $(call if_changed,make_module_acl) > + > +$(obj)/clavis_module_acl.o: $(obj)/module_acl > + > +targets += module_acl > + > $(obj)/revocation_certificates.o: $(obj)/x509_revocation_list > > $(obj)/x509_revocation_list: $(CONFIG_SYSTEM_REVOCATION_KEYS) > $(obj)/extract-cert FORCE > diff --git a/certs/clavis_module_acl.c b/certs/clavis_module_acl.c > new file mode 100644 > index 000000000000..fc2f694c48f9 > --- /dev/null > +++ b/certs/clavis_module_acl.c > @@ -0,0 +1,7 @@ > +// SPDX-License-Identifier: GPL-2.0 > +#include <linux/kernel.h> > + > +const char __initconst *const clavis_module_acl[] = { > +#include "module_acl" > + NULL > +}; > diff --git a/security/clavis/clavis.h b/security/clavis/clavis.h > index 7b55a6050440..92f77a1939ad 100644 > --- a/security/clavis/clavis.h > +++ b/security/clavis/clavis.h > @@ -11,4 +11,13 @@ struct asymmetric_setup_kid { > struct asymmetric_key_id id; > unsigned char data[CLAVIS_BIN_KID_MAX]; > }; > + > +#ifndef CONFIG_SYSTEM_TRUSTED_KEYRING > +const char __initconst *const clavis_module_acl[] = { > + NULL > +}; > +#else > +extern const char __initconst *const clavis_module_acl[]; > +#endif > + > #endif /* _SECURITY_CLAVIS_H_ */ > diff --git a/security/clavis/clavis_keyring.c > b/security/clavis/clavis_keyring.c > index 00163e7f0fe9..2a18d0e77189 100644 > --- a/security/clavis/clavis_keyring.c > +++ b/security/clavis/clavis_keyring.c > @@ -259,6 +259,31 @@ static struct key_restriction > *clavis_restriction_alloc(key_restrict_link_func_t > return restriction; > } > > +static void clavis_add_acl(const char *const *skid_list, struct key > *keyring) > +{ > + const char *const *acl; > + key_ref_t key; > + > + for (acl = skid_list; *acl; acl++) { > + key = key_create(make_key_ref(keyring, true), > + "clavis_key_acl", > + *acl, > + NULL, > + 0, > + KEY_POS_SEARCH | KEY_POS_VIEW | > KEY_USR_SEARCH | KEY_USR_VIEW, > + KEY_ALLOC_NOT_IN_QUOTA | > KEY_ALLOC_BUILT_IN | > + KEY_ALLOC_BYPASS_RESTRICTION); > + if (IS_ERR(key)) { > + if (PTR_ERR(key) == -EEXIST) > + pr_info("Duplicate clavis_key_acl > %s\n", *acl); > + else > + pr_info("Problem with clavis_key_acl > %s: %pe\n", *acl, key); > + } else { > + pr_info("Added clavis_key_acl %s\n", *acl); > + } > + } > +} > + > static int __init clavis_keyring_init(void) > { > struct key_restriction *restriction; > @@ -274,6 +299,8 @@ static int __init clavis_keyring_init(void) > if (IS_ERR(clavis_keyring)) > panic("Can't allocate clavis keyring\n"); > > + clavis_add_acl(clavis_module_acl, clavis_keyring); > + > return 0; > } > Not yet tagging, but neither anything to complain. LGTM BR, Jarkko
> On Oct 17, 2024, at 10:50 AM, Jarkko Sakkinen <jarkko@kernel.org> wrote: > > On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote: >> +static struct asymmetric_key_id *clavis_parse_boot_param(char *kid, >> struct asymmetric_key_id *akid, >> + int >> akid_max_len) >> +{ >> + int error, hex_len; >> + >> + if (!kid) >> + return 0; >> + >> + hex_len = strlen(kid) / 2; > > Hmmm... I'd consider sanity checking this: > > size_t len; > > /* ... */ > > len = strlen(kid); > if (len % 2) { > pr_err("Clavis key id has invalid length %lu\n", len); > return 0; > } > > hex_len = len / 2; > Good catch, I will include this in the next round. I have also added a kunit test for this as well. Thanks.
On Thu, 2024-10-17 at 20:34 +0000, Eric Snowberg wrote: > > > > On Oct 17, 2024, at 10:50 AM, Jarkko Sakkinen <jarkko@kernel.org> > > wrote: > > > > On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote: > > > +static struct asymmetric_key_id *clavis_parse_boot_param(char > > > *kid, > > > struct asymmetric_key_id *akid, > > > + int > > > akid_max_len) > > > +{ > > > + int error, hex_len; > > > + > > > + if (!kid) > > > + return 0; > > > + > > > + hex_len = strlen(kid) / 2; > > > > Hmmm... I'd consider sanity checking this: > > > > size_t len; > > > > /* ... */ > > > > len = strlen(kid); > > if (len % 2) { > > pr_err("Clavis key id has invalid length %lu\n", len); > > return 0; > > } > > > > hex_len = len / 2; > > > > Good catch, I will include this in the next round. I have also added > a kunit test > for this as well. Thanks. I guess hex2bin() would eventually catch this issue, i.e. not an actual bug, but I still think that you are better off doing also check here and get an appropriate message to klog if that ever happens :-) BR, Jarkko
> On Oct 17, 2024, at 1:20 PM, Jarkko Sakkinen <jarkko@kernel.org> wrote: > > On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote: >> Add a new verification type called VERIFYING_CLAVIS_SIGNATURE. This >> new >> usage will be used for validating keys added to the new clavis LSM >> keyring. >> This will be introduced in a follow-on patch. >> >> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com> >> --- >> crypto/asymmetric_keys/asymmetric_type.c | 1 + >> crypto/asymmetric_keys/pkcs7_verify.c | 1 + >> include/linux/verification.h | 2 ++ >> 3 files changed, 4 insertions(+) >> >> diff --git a/crypto/asymmetric_keys/asymmetric_type.c >> b/crypto/asymmetric_keys/asymmetric_type.c >> index 43af5fa510c0..d7bf95c77f4a 100644 >> --- a/crypto/asymmetric_keys/asymmetric_type.c >> +++ b/crypto/asymmetric_keys/asymmetric_type.c >> @@ -25,6 +25,7 @@ const char *const >> key_being_used_for[NR__KEY_BEING_USED_FOR] = { >> [VERIFYING_KEY_SIGNATURE] = "key sig", >> [VERIFYING_KEY_SELF_SIGNATURE] = "key self sig", >> [VERIFYING_UNSPECIFIED_SIGNATURE] = "unspec sig", >> + [VERIFYING_CLAVIS_SIGNATURE] = "clavis sig", >> }; >> EXPORT_SYMBOL_GPL(key_being_used_for); >> >> diff --git a/crypto/asymmetric_keys/pkcs7_verify.c >> b/crypto/asymmetric_keys/pkcs7_verify.c >> index f0d4ff3c20a8..1dc80e68ce96 100644 >> --- a/crypto/asymmetric_keys/pkcs7_verify.c >> +++ b/crypto/asymmetric_keys/pkcs7_verify.c >> @@ -428,6 +428,7 @@ int pkcs7_verify(struct pkcs7_message *pkcs7, >> } >> /* Authattr presence checked in parser */ >> break; >> + case VERIFYING_CLAVIS_SIGNATURE: >> case VERIFYING_UNSPECIFIED_SIGNATURE: >> if (pkcs7->data_type != OID_data) { >> pr_warn("Invalid unspecified sig (not pkcs7- >> data)\n"); >> diff --git a/include/linux/verification.h >> b/include/linux/verification.h >> index cb2d47f28091..02d2d70e2324 100644 >> --- a/include/linux/verification.h >> +++ b/include/linux/verification.h >> @@ -36,6 +36,8 @@ enum key_being_used_for { >> VERIFYING_KEY_SIGNATURE, >> VERIFYING_KEY_SELF_SIGNATURE, >> VERIFYING_UNSPECIFIED_SIGNATURE, >> + /* Add new entries above, keep VERIFYING_CLAVIS_SIGNATURE at >> the end. */ >> + VERIFYING_CLAVIS_SIGNATURE, >> NR__KEY_BEING_USED_FOR >> }; >> extern const char *const key_being_used_for[NR__KEY_BEING_USED_FOR]; > > This looks as good as it can get. Just wondering that does this Clavis > thing connect with the TPM2 asymmetric keys that I've been working on? > I.e. can they be used in tandem. I should really update that patch set > (latest from April). With some changes, I think they could be used in tandem. If I'm looking at the correct series, tpm2_key_rsa_describe would need to be changed to return a unique identifier, instead of "TPM2/RSA". This identifier could be used instead of the skid when creating a Clavis ACL. There would probably also need to be a new system kernel keyring containing these TPM keys. Similar to the builtin, secondary, machine, etc.
On Thu, 2024-10-17 at 21:42 +0000, Eric Snowberg wrote: > > > > On Oct 17, 2024, at 1:20 PM, Jarkko Sakkinen <jarkko@kernel.org> > > wrote: > > > > On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote: > > > Add a new verification type called VERIFYING_CLAVIS_SIGNATURE. > > > This > > > new > > > usage will be used for validating keys added to the new clavis > > > LSM > > > keyring. > > > This will be introduced in a follow-on patch. > > > > > > Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com> > > > --- > > > crypto/asymmetric_keys/asymmetric_type.c | 1 + > > > crypto/asymmetric_keys/pkcs7_verify.c | 1 + > > > include/linux/verification.h | 2 ++ > > > 3 files changed, 4 insertions(+) > > > > > > diff --git a/crypto/asymmetric_keys/asymmetric_type.c > > > b/crypto/asymmetric_keys/asymmetric_type.c > > > index 43af5fa510c0..d7bf95c77f4a 100644 > > > --- a/crypto/asymmetric_keys/asymmetric_type.c > > > +++ b/crypto/asymmetric_keys/asymmetric_type.c > > > @@ -25,6 +25,7 @@ const char *const > > > key_being_used_for[NR__KEY_BEING_USED_FOR] = { > > > [VERIFYING_KEY_SIGNATURE] = "key sig", > > > [VERIFYING_KEY_SELF_SIGNATURE] = "key self sig", > > > [VERIFYING_UNSPECIFIED_SIGNATURE] = "unspec sig", > > > + [VERIFYING_CLAVIS_SIGNATURE] = "clavis sig", > > > }; > > > EXPORT_SYMBOL_GPL(key_being_used_for); > > > > > > diff --git a/crypto/asymmetric_keys/pkcs7_verify.c > > > b/crypto/asymmetric_keys/pkcs7_verify.c > > > index f0d4ff3c20a8..1dc80e68ce96 100644 > > > --- a/crypto/asymmetric_keys/pkcs7_verify.c > > > +++ b/crypto/asymmetric_keys/pkcs7_verify.c > > > @@ -428,6 +428,7 @@ int pkcs7_verify(struct pkcs7_message *pkcs7, > > > } > > > /* Authattr presence checked in parser */ > > > break; > > > + case VERIFYING_CLAVIS_SIGNATURE: > > > case VERIFYING_UNSPECIFIED_SIGNATURE: > > > if (pkcs7->data_type != OID_data) { > > > pr_warn("Invalid unspecified sig (not pkcs7- > > > data)\n"); > > > diff --git a/include/linux/verification.h > > > b/include/linux/verification.h > > > index cb2d47f28091..02d2d70e2324 100644 > > > --- a/include/linux/verification.h > > > +++ b/include/linux/verification.h > > > @@ -36,6 +36,8 @@ enum key_being_used_for { > > > VERIFYING_KEY_SIGNATURE, > > > VERIFYING_KEY_SELF_SIGNATURE, > > > VERIFYING_UNSPECIFIED_SIGNATURE, > > > + /* Add new entries above, keep VERIFYING_CLAVIS_SIGNATURE at > > > the end. */ > > > + VERIFYING_CLAVIS_SIGNATURE, > > > NR__KEY_BEING_USED_FOR > > > }; > > > extern const char *const > > > key_being_used_for[NR__KEY_BEING_USED_FOR]; > > > > This looks as good as it can get. Just wondering that does this > > Clavis > > thing connect with the TPM2 asymmetric keys that I've been working > > on? > > I.e. can they be used in tandem. I should really update that patch > > set > > (latest from April). > > With some changes, I think they could be used in tandem. If I'm > looking at > the correct series, tpm2_key_rsa_describe would need to be changed to > return a unique identifier, instead of "TPM2/RSA". This identifier > could be > used instead of the skid when creating a Clavis ACL. There would > probably > also need to be a new system kernel keyring containing these TPM > keys. > Similar to the builtin, secondary, machine, etc. I think when I finally get into working on this again I focus on purely to get ECDSA right. Thanks for the tip, most likely this revamp will happen post your patch set. I'm still busy fixing corner cases with the bus encryption that James Bottomley contributed. BR, Jarkko
On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote: > Motivation: > > Each end-user has their own security threat model. What is important to one > end-user may not be important to another. There is not a right or wrong threat > model. > > A common request made when adding new kernel changes that could impact the > threat model around system kernel keys is to add additional Kconfig options. > As kernel developers, it is challenging to both add and keep track of all the > Kconfig options around security features that may limit or restrict > system key usage. It is also difficult for a general purpose distro to take > advantage of some of these features, since it may prevent some users from > executing their workload. > > It is the author's belief that it is better left up to the end-user on how > kernel keys should be used within their system. > > Throughout the Linux kernel, key usage is tracked when doing signature > verification with keys contained within one of the system keyrings; however, > there isn't a way for the end-user to enforce this usage. This series gives the > end-user the ability to configure key usage based on their threat model. > Having the ability to enforce key usage also improves security by reducing the > attack surface should a system key be compromised. It allows new features to be > added without the need for additional Kconfig options for fear of changing the > end-user's threat model. It also allows a distro to build a kernel that suits > various end-user's needs without resorting to selecting Kconfig options with > the least restrictive security options. The motivation for this patch set is convincing and addresses limiting the usage of keys loaded directly or indirectly onto the system trusted keyrings - .builtin, .machine, and .secondary_trusted_keys keyrings. Pre-loading the build time ephemeral kernel module signing key is a nice improvement from the previous versions. My main concern is not with Clavis per-se, but that the LSM infrastructure allows configuring all the LSMs, but enabling at build time and modifying at runtime a subset of them. Without Clavis enabled, nothing changes - any key on the system trusted keyrings remains usable for any purpose. With the current LSM design, the end user security threat model cannot be guaranteed. Mimi > > Solution: > > This series introduces a new LSM called Clavis (Latin word meaning key). > This LSM leaves it up to the end-user to determine what system keys they want > to use and for what purpose. > > The Clavis LSM adds the ability to do access control for all system keys. When > enabled, until an ACL entry is added for a specific key, none of the system keys > may be used for any type of verification purpose. When the kernel is built, > typically kernel modules are signed with an ephemeral key, an ACL entry for the > ephemeral key is pre-loaded, allowing the kernel modules to load during boot. At > build time other ACL entries may also be included. > > The Clavis LSM requires the end-user to have their own public key infrastructure > (PKI). In order for a Clavis ACL entry to be added, the ACL must be signed by > what is being called the Clavis key. The Clavis key is owned by the end-user. > The Clavis public key can be contained within the machine keyring, or it can be > added after the machine boots. > > Not only is there a new Clavis key being introduced, but there is also a new > .clavis keyring. The .clavis keyring contains a single Clavis key. It also > contains any number of ACL entries that are signed by the Clavis key. > > It is believed that the most common setup would be to have the Clavis key > contained within the machine keyring. Enabling the Clavis LSM during boot is > accomplished by passing in the asymmetric key id for the Clavis key within a > new "clavis=" boot param. The asymmetric key id must match one already > contained within any of the system keyrings. If a match is found, a link is > created into the new .clavis keyring. This Clavis key shall be used as the > root of trust for any keyring ACL updates afterwards. > > On UEFI systems the "clavis" boot param is mirrored into a new UEFI variable > within the EFI stub code. This variable will persist until the next reboot. > This same type of functionality is done within shim. Since this variable is > created before ExitBootServices (EBS) it will not have the NVRAM bit set, > signifying it was created during the Boot Services phase. This is being used > so the "clavis" boot param can not be changed via kexec, thereby preventing a > pivot of the root of trust. > > As mentioned earlier, this LSM introduces a new .clavis keyring. Following > boot, no new keys can be added to this keyring and only the key designated via > the initial boot param may be used. If the clavis boot param was not used, the > LSM can be enabled afterwards using the keyctl command. The end-user may add > their Clavis key into the .clavis keyring and the Clavis LSM shall be enabled. > > The .clavis keyring also holds the access control list for system keys. A new > key type called clavis_key_acl is being introduced. This contains the usage > followed by the asymmetric key id. To be added to the clavis keyring, the > clavis_key_acl must be S/MIME signed by the Clavis key. New ACL additions to > the .clavis keyring may be added at any time. > > Currently this LSM does not require new changes or modifications to any user > space tools. It also does not have a securityfs interface. Everything is > done using the existing keyctl tool through the new .clavis keyring. The > S/MIME signing can be done with a simple OpenSSL command. If additions or > updates need to be added in the future, new ACL key types could be created. > With this approach, maintainability should not be an issue in the future > if missing items are identified. > > Clavis must be configured at build time with CONFIG_SECURITY_CLAVIS=y. The list > of security modules enabled by default is set with CONFIG_LSM. The kernel > configuration must contain CONFIG_LSM=[...],clavis with [...] as the list of > other security modules for the running system. > > For setup and usage instructions, a clavis admin-guide has been included > in Documentation/admin-guide/LSM/clavis.rst. > > Future enhancements to this LSM could include: > > 1. Subsystems that currently use system keys with > VERIFYING_UNSPECIFIED_SIGNATURE could be updated with their specific usage > type. For example, a usage type for IMA, BPF, etc could be added. > > 2. Having the ability to allow platform keys to be on par with all other > system keys when using this LSM. This would be useful for a user that > controls their entire UEFI SB DB key chain and doesn't want to use MOK keys. > This could also potentially remove the need for the machine keyring all > together. > > 3. Some of the Kconfig options around key usage and types could be deprecated. > > I would appreciate any feedback on this approach. Thanks. > > Changes in v3: > Rebased to 6.12-rc3 > Added Kunit test code > Preload an ACL in the clavis keyring with the ephemeral module signing key > Preload user defined ACL data into the clavis keyring with build time data > Changes to the second patch recommended by Jarkko > Reordered patches recommended by Mimi > Documentation improvements recommended by Randy > > Changes in v2: > Rebased to 6.10-rc1 > Various cleanup in the first patch recommended by Jarkko > Documentation improvements recommended by Randy > Fixed lint warnings > Other cleanup > > Eric Snowberg (13): > certs: Remove CONFIG_INTEGRITY_PLATFORM_KEYRING check > certs: Introduce ability to link to a system key > clavis: Introduce a new system keyring called clavis > keys: Add new verification type (VERIFYING_CLAVIS_SIGNATURE) > clavis: Introduce a new key type called clavis_key_acl > clavis: Populate clavis keyring acl with kernel module signature > keys: Add ability to track intended usage of the public key > clavis: Introduce new LSM called clavis > clavis: Allow user to define acl at build time > efi: Make clavis boot param persist across kexec > clavis: Prevent boot param change during kexec > clavis: Add function redirection for Kunit support > clavis: Kunit support > > Documentation/admin-guide/LSM/clavis.rst | 191 ++++++ > .../admin-guide/kernel-parameters.txt | 6 + > MAINTAINERS | 7 + > certs/.gitignore | 1 + > certs/Makefile | 20 + > certs/blacklist.c | 3 + > certs/clavis_module_acl.c | 7 + > certs/system_keyring.c | 36 +- > crypto/asymmetric_keys/asymmetric_type.c | 1 + > crypto/asymmetric_keys/pkcs7_trust.c | 20 + > crypto/asymmetric_keys/pkcs7_verify.c | 5 + > crypto/asymmetric_keys/signature.c | 4 + > drivers/firmware/efi/Kconfig | 12 + > drivers/firmware/efi/libstub/Makefile | 1 + > drivers/firmware/efi/libstub/clavis.c | 33 + > .../firmware/efi/libstub/efi-stub-helper.c | 2 + > drivers/firmware/efi/libstub/efi-stub.c | 2 + > drivers/firmware/efi/libstub/efistub.h | 8 + > drivers/firmware/efi/libstub/x86-stub.c | 2 + > include/crypto/pkcs7.h | 3 + > include/crypto/public_key.h | 4 + > include/keys/system_keyring.h | 7 +- > include/linux/efi.h | 1 + > include/linux/integrity.h | 8 + > include/linux/lsm_count.h | 8 +- > include/linux/lsm_hook_defs.h | 2 + > include/linux/security.h | 7 + > include/linux/verification.h | 2 + > include/uapi/linux/lsm.h | 1 + > security/Kconfig | 11 +- > security/Makefile | 1 + > security/clavis/.gitignore | 2 + > security/clavis/.kunitconfig | 4 + > security/clavis/Kconfig | 37 ++ > security/clavis/Makefile | 156 +++++ > security/clavis/clavis.c | 26 + > security/clavis/clavis.h | 62 ++ > security/clavis/clavis_builtin_acl.c | 7 + > security/clavis/clavis_efi.c | 50 ++ > security/clavis/clavis_keyring.c | 426 +++++++++++++ > security/clavis/clavis_test.c | 566 ++++++++++++++++++ > security/integrity/iint.c | 2 + > security/security.c | 13 + > .../selftests/lsm/lsm_list_modules_test.c | 3 + > 44 files changed, 1757 insertions(+), 13 deletions(-) > create mode 100644 Documentation/admin-guide/LSM/clavis.rst > create mode 100644 certs/clavis_module_acl.c > create mode 100644 drivers/firmware/efi/libstub/clavis.c > create mode 100644 security/clavis/.gitignore > create mode 100644 security/clavis/.kunitconfig > create mode 100644 security/clavis/Kconfig > create mode 100644 security/clavis/Makefile > create mode 100644 security/clavis/clavis.c > create mode 100644 security/clavis/clavis.h > create mode 100644 security/clavis/clavis_builtin_acl.c > create mode 100644 security/clavis/clavis_efi.c > create mode 100644 security/clavis/clavis_keyring.c > create mode 100644 security/clavis/clavis_test.c > > > base-commit: 8e929cb546ee42c9a61d24fae60605e9e3192354
Hi Mimi, > On Dec 23, 2024, at 5:09 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: > > On Thu, 2024-10-17 at 09:55 -0600, Eric Snowberg wrote: >> Motivation: >> >> Each end-user has their own security threat model. What is important to one >> end-user may not be important to another. There is not a right or wrong threat >> model. >> >> A common request made when adding new kernel changes that could impact the >> threat model around system kernel keys is to add additional Kconfig options. >> As kernel developers, it is challenging to both add and keep track of all the >> Kconfig options around security features that may limit or restrict >> system key usage. It is also difficult for a general purpose distro to take >> advantage of some of these features, since it may prevent some users from >> executing their workload. >> >> It is the author's belief that it is better left up to the end-user on how >> kernel keys should be used within their system. >> >> Throughout the Linux kernel, key usage is tracked when doing signature >> verification with keys contained within one of the system keyrings; however, >> there isn't a way for the end-user to enforce this usage. This series gives the >> end-user the ability to configure key usage based on their threat model. >> Having the ability to enforce key usage also improves security by reducing the >> attack surface should a system key be compromised. It allows new features to be >> added without the need for additional Kconfig options for fear of changing the >> end-user's threat model. It also allows a distro to build a kernel that suits >> various end-user's needs without resorting to selecting Kconfig options with >> the least restrictive security options. > > The motivation for this patch set is convincing and addresses limiting the usage > of keys loaded directly or indirectly onto the system trusted keyrings - > .builtin, .machine, and .secondary_trusted_keys keyrings. Pre-loading the build > time ephemeral kernel module signing key is a nice improvement from the previous > versions. Apologies for the delayed response and thanks for your feedback on this and the other patches you reviewed in the series. > My main concern is not with Clavis per-se, but that the LSM > infrastructure allows configuring all the LSMs, but enabling at build time and > modifying at runtime a subset of them. Without Clavis enabled, nothing changes > - any key on the system trusted keyrings remains usable for any purpose. With > the current LSM design, the end user security threat model cannot be guaranteed. I went in the direction of creating a new LSM based on this discussion [1]. I was hoping to get some feedback from Paul, since I believe I have addressed the guidelines for a new LSM. Currently, the Clavis LSM only adds a single LSM hook. To address your concern, maybe Clavis shouldn't be a LSM? Possibly it could live in the keyring code on its own. 1. https://lkml.org/lkml/2023/10/5/312
On Fri, Jan 3, 2025 at 6:14 PM Eric Snowberg <eric.snowberg@oracle.com> wrote: > > On Dec 23, 2024, at 5:09 AM, Mimi Zohar <zohar@linux.ibm.com> wrote: ... > > My main concern is not with Clavis per-se, but that the LSM > > infrastructure allows configuring all the LSMs, but enabling at build time and > > modifying at runtime a subset of them. Without Clavis enabled, nothing changes > > - any key on the system trusted keyrings remains usable for any purpose. With > > the current LSM design, the end user security threat model cannot be guaranteed. > > I went in the direction of creating a new LSM based on this discussion [1]. > I was hoping to get some feedback from Paul, since I believe I have > addressed the guidelines for a new LSM. Currently, the Clavis LSM only > adds a single LSM hook. To address your concern, maybe Clavis shouldn't > be a LSM? Possibly it could live in the keyring code on its own. My turn to apologize for a very late reply, you've been very patient and I appreciate that. With respect to Mimi's concerns about disabling Clavis, or any LSM for that matter, at runtime, doing so requires the ability to modify the kernel's command line. I would argue that if a user can manipulate the kernel command line there are more serious issues that need to be dealt with first. Any user who is seriously concerned about the state of their system should have some mechanism in place to ensure that the kernel command line is not subject to tampering; thankfully there are efforts underway to help bring tamper resistant command lines to a larger audience (the UKI work). I can't remember if anyone has ever brought this up on-list, and if so what objections there may have been, but I've always wondered if the real problem is simply that we use a handful of keyrings for far too many things inside the kernel. What terrible things would need to be overcome if we created additional keyrings based on usage, e.g. ".modulesigning", and used these task specific keyrings instead of the existing source/trust oriented keyrings? I imagine we would likely need some mechanism to link a key from the existing source/trust keyrings, e.g. ".machine", to a task specific keyring, e.g. ".modulesigning", but I can't imagine that would be too difficult. Regardless, back to Clavis ... reading quickly through the cover letter again, I do somewhat wonder if this isn't better integrated into the keyring proper; have you talked to both David and Jarkko about this? Were they supportive of the idea, but simply felt it was better as an LSM? I see Jarkko has reviewed and commented on a number of the patches, so I'll take that as an implicit acceptance of the concept, but have you heard anything from David?
On Fri, Jan 3, 2025 at 11:48 PM Paul Moore <paul@paul-moore.com> wrote: > > Regardless, back to Clavis ... reading quickly through the cover > letter again, I do somewhat wonder if this isn't better integrated > into the keyring proper; have you talked to both David and Jarkko > about this? I realize I should probably expand on my thinking a bit, especially since my comment a while regarding LSMs dedicated to enforcing access control on keys is what was given as a reason for making Clavis a LSM. I still stand by my comment from over a year ago that I see no reason why we couldn't support a LSM that enforces access controls on keyrings/keys. What gives me pause with the Clavis LSM is that so much of Clavis is resident in the keyrings themselves, e.g. Clavis policy ACLs and authorization keys, that it really feels like it should be part of the keys subsystem and not a LSM. Yes, existing LSMs do have LSM specific data that resides outside of the LSM and in an object's subsystem, but that is usually limited to security identifiers and similar things, not the LSM's security policy. That's my current thinking, and why I asked about locating Clavis in the keys subsystem directly (although I still think better keyring granularity and a shift towards usage based keyrings is the better option). If David and Jarkko are opposed to integrating Clavis into the keys subsystem we can consider this as a LSM, I'm just not sure it's the best first option. Does that make sense?
> On Jan 5, 2025, at 8:40 PM, Paul Moore <paul@paul-moore.com> wrote: > > On Fri, Jan 3, 2025 at 11:48 PM Paul Moore <paul@paul-moore.com> wrote: >> >> Regardless, back to Clavis ... reading quickly through the cover >> letter again, I do somewhat wonder if this isn't better integrated >> into the keyring proper; have you talked to both David and Jarkko >> about this? > > I realize I should probably expand on my thinking a bit, especially > since my comment a while regarding LSMs dedicated to enforcing access > control on keys is what was given as a reason for making Clavis a LSM. > > I still stand by my comment from over a year ago that I see no reason > why we couldn't support a LSM that enforces access controls on > keyrings/keys. What gives me pause with the Clavis LSM is that so > much of Clavis is resident in the keyrings themselves, e.g. Clavis > policy ACLs and authorization keys, that it really feels like it > should be part of the keys subsystem and not a LSM. Yes, existing > LSMs do have LSM specific data that resides outside of the LSM and in > an object's subsystem, but that is usually limited to security > identifiers and similar things, not the LSM's security policy. > > That's my current thinking, and why I asked about locating Clavis in > the keys subsystem directly (although I still think better keyring > granularity and a shift towards usage based keyrings is the better > option). If David and Jarkko are opposed to integrating Clavis into > the keys subsystem we can consider this as a LSM, I'm just not sure > it's the best first option. Does that make sense? Thanks for your feedback Paul. I have no preference if it is a new LSM or not. My interest is finding the path of least resistance to get this type of capability added to mainline code. Hopefully David and Jarkko will provide their opinions.
On Mon, 2025-01-06 at 17:15 +0000, Eric Snowberg wrote: > > > On Jan 5, 2025, at 8:40 PM, Paul Moore <paul@paul-moore.com> wrote: > > > > On Fri, Jan 3, 2025 at 11:48 PM Paul Moore <paul@paul-moore.com> wrote: > > > > > > Regardless, back to Clavis ... reading quickly through the cover > > > letter again, I do somewhat wonder if this isn't better integrated > > > into the keyring proper; have you talked to both David and Jarkko > > > about this? > > > > I realize I should probably expand on my thinking a bit, especially > > since my comment a while regarding LSMs dedicated to enforcing access > > control on keys is what was given as a reason for making Clavis a LSM. > > > > I still stand by my comment from over a year ago that I see no reason > > why we couldn't support a LSM that enforces access controls on > > keyrings/keys. What gives me pause with the Clavis LSM is that so > > much of Clavis is resident in the keyrings themselves, e.g. Clavis > > policy ACLs and authorization keys, that it really feels like it > > should be part of the keys subsystem and not a LSM. Yes, existing > > LSMs do have LSM specific data that resides outside of the LSM and in > > an object's subsystem, but that is usually limited to security > > identifiers and similar things, not the LSM's security policy. Hi Jarkko, David, Both Paul's and my main concerns with this patch set is storing policy in the keyring. We would appreciate your chiming in here about storing key policy in the keyring itself. thanks, Mimi > > > > That's my current thinking, and why I asked about locating Clavis in > > the keys subsystem directly (although I still think better keyring > > granularity and a shift towards usage based keyrings is the better > > option). If David and Jarkko are opposed to integrating Clavis into > > the keys subsystem we can consider this as a LSM, I'm just not sure > > it's the best first option. Does that make sense? > > Thanks for your feedback Paul. I have no preference if it is a new LSM > or not. My interest is finding the path of least resistance to get this type > of capability added to mainline code. Hopefully David and Jarkko will > provide their opinions.
On Thu, Feb 27, 2025 at 3:41 PM Mimi Zohar <zohar@linux.ibm.com> wrote: > On Mon, 2025-01-06 at 17:15 +0000, Eric Snowberg wrote: > > > On Jan 5, 2025, at 8:40 PM, Paul Moore <paul@paul-moore.com> wrote: > > > On Fri, Jan 3, 2025 at 11:48 PM Paul Moore <paul@paul-moore.com> wrote: > > > > > > > > Regardless, back to Clavis ... reading quickly through the cover > > > > letter again, I do somewhat wonder if this isn't better integrated > > > > into the keyring proper; have you talked to both David and Jarkko > > > > about this? > > > > > > I realize I should probably expand on my thinking a bit, especially > > > since my comment a while regarding LSMs dedicated to enforcing access > > > control on keys is what was given as a reason for making Clavis a LSM. > > > > > > I still stand by my comment from over a year ago that I see no reason > > > why we couldn't support a LSM that enforces access controls on > > > keyrings/keys. What gives me pause with the Clavis LSM is that so > > > much of Clavis is resident in the keyrings themselves, e.g. Clavis > > > policy ACLs and authorization keys, that it really feels like it > > > should be part of the keys subsystem and not a LSM. Yes, existing > > > LSMs do have LSM specific data that resides outside of the LSM and in > > > an object's subsystem, but that is usually limited to security > > > identifiers and similar things, not the LSM's security policy. > > Hi Jarkko, David, > > Both Paul's and my main concerns with this patch set is storing policy in the > keyring. We would appreciate your chiming in here about storing key policy in > the keyring itself. I'd still also like to see some discussion about moving towards the addition of keyrings oriented towards usage instead of limiting ourselves to keyrings that are oriented on the source of the keys. Perhaps I'm missing some important detail which makes this impractical, but it seems like an obvious improvement to me and would go a long way towards solving some of the problems that we typically see with kernel keys.
On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote: > On Thu, Feb 27, 2025 at 3:41 PM Mimi Zohar <zohar@linux.ibm.com> wrote: > > On Mon, 2025-01-06 at 17:15 +0000, Eric Snowberg wrote: > > > > On Jan 5, 2025, at 8:40 PM, Paul Moore <paul@paul-moore.com> wrote: > > > > On Fri, Jan 3, 2025 at 11:48 PM Paul Moore <paul@paul-moore.com> wrote: > > > > > > > > > > Regardless, back to Clavis ... reading quickly through the cover > > > > > letter again, I do somewhat wonder if this isn't better integrated > > > > > into the keyring proper; have you talked to both David and Jarkko > > > > > about this? > > > > > > > > I realize I should probably expand on my thinking a bit, especially > > > > since my comment a while regarding LSMs dedicated to enforcing access > > > > control on keys is what was given as a reason for making Clavis a LSM. > > > > > > > > I still stand by my comment from over a year ago that I see no reason > > > > why we couldn't support a LSM that enforces access controls on > > > > keyrings/keys. What gives me pause with the Clavis LSM is that so > > > > much of Clavis is resident in the keyrings themselves, e.g. Clavis > > > > policy ACLs and authorization keys, that it really feels like it > > > > should be part of the keys subsystem and not a LSM. Yes, existing > > > > LSMs do have LSM specific data that resides outside of the LSM and in > > > > an object's subsystem, but that is usually limited to security > > > > identifiers and similar things, not the LSM's security policy. > > > > Hi Jarkko, David, > > > > Both Paul's and my main concerns with this patch set is storing policy in the > > keyring. We would appreciate your chiming in here about storing key policy in > > the keyring itself. > > I'd still also like to see some discussion about moving towards the > addition of keyrings oriented towards usage instead of limiting > ourselves to keyrings that are oriented on the source of the keys. > Perhaps I'm missing some important detail which makes this > impractical, but it seems like an obvious improvement to me and would > go a long way towards solving some of the problems that we typically > see with kernel keys. The proliferation of keyrings won't solve the key usage problem for IMA- appraisal. IMA-appraisal can be used to verify the kexec image, kernel modules, firwmare, etc, but it also verifies file signatures contained in userspace packages. To support the latter case, keyrings would need to be application specific. (This version of Clavis doesn't solve the latter key usage for IMA- appraisal either.) The keys baked into the kernel are trusted because the kernel itself was signed and verified (secure boot). Anyone building a kernel can build a key into the kernel image, which establishes a "root of trust". That key can then be used to verify and load other keys onto the IMA keyring. The problem is how to safely establish a root of trust without baking the key into the kernel image and then limiting that trust to specific usages or applications. Mimi
On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote: > > > > I'd still also like to see some discussion about moving towards the > > addition of keyrings oriented towards usage instead of limiting > > ourselves to keyrings that are oriented on the source of the keys. > > Perhaps I'm missing some important detail which makes this > > impractical, but it seems like an obvious improvement to me and would > > go a long way towards solving some of the problems that we typically > > see with kernel keys. > > The proliferation of keyrings won't solve the key usage problem for IMA- > appraisal. IMA-appraisal can be used to verify the kexec image, kernel modules, > firwmare, etc, but it also verifies file signatures contained in userspace > packages. To be clear I don't think the usage oriented keyring idea will solve every keyring problem, but it seems like it solves a fair number of things that I've heard lately. > To support the latter case, keyrings would need to be application > specific. (This version of Clavis doesn't solve the latter key usage for IMA- > appraisal either.) Application specific keyrings are more-or-less what I've been trying to describe. > The keys baked into the kernel are trusted because the kernel itself was signed > and verified (secure boot). Anyone building a kernel can build a key into the > kernel image, which establishes a "root of trust". That key can then be used to > verify and load other keys onto the IMA keyring. Sure, I'm not saying that trust isn't important, and that there are varying levels of trust. My argument is that having additional, usage/application oriented keyrings which contain links back to keys imported and stored in the traditional trust oriented keyrings could neatly solve a number of keyring access control issues. > The problem is how to safely establish a root of trust without baking the key > into the kernel image and then limiting that trust to specific usages or > applications. My takeaway from Clavis was that it was more about establishing a set of access controls around keys already present in the keyrings and my comments about usage/spplication oriented keyrings have been in that context. While the access control policy, regardless of how it is implemented, should no doubt incorporate the trust placed in the individual keys, how that trust is established is a separate issue from access control as far as I'm concerned.
On Fri, 2025-02-28 at 11:14 -0500, Paul Moore wrote: > On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > > On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote: > > > > > > I'd still also like to see some discussion about moving towards the > > > addition of keyrings oriented towards usage instead of limiting > > > ourselves to keyrings that are oriented on the source of the keys. > > > Perhaps I'm missing some important detail which makes this > > > impractical, but it seems like an obvious improvement to me and would > > > go a long way towards solving some of the problems that we typically > > > see with kernel keys. > > > > The proliferation of keyrings won't solve the key usage problem for IMA- > > appraisal. IMA-appraisal can be used to verify the kexec image, kernel modules, > > firwmare, etc, but it also verifies file signatures contained in userspace > > packages. > > To be clear I don't think the usage oriented keyring idea will solve > every keyring problem, but it seems like it solves a fair number of > things that I've heard lately. > > > To support the latter case, keyrings would need to be application > > specific. (This version of Clavis doesn't solve the latter key usage for IMA- > > appraisal either.) > > Application specific keyrings are more-or-less what I've been trying > to describe. Ok, let's go through different scenarios to see if it would scale. Scenario 1: Mostly distro signed userspace applications, minimum number of developer, customer, 3rd party applications. Scenario 2: Multiple developer, customer, 3rd party applications, signed by the same party. Scenario 3: extreme case - every application signed by different party. With the minimum case, there would probably be a default key or sets of permissible keys. In the extreme case, the number of keyrings would be equivalent to the number of application/software packages. > > > The keys baked into the kernel are trusted because the kernel itself was signed > > and verified (secure boot). Anyone building a kernel can build a key into the > > kernel image, which establishes a "root of trust". That key can then be used to > > verify and load other keys onto the IMA keyring. > > Sure, I'm not saying that trust isn't important, and that there are > varying levels of trust. My argument is that having additional, > usage/application oriented keyrings which contain links back to keys > imported and stored in the traditional trust oriented keyrings could > neatly solve a number of keyring access control issues. > > > The problem is how to safely establish a root of trust without baking the key > > into the kernel image and then limiting that trust to specific usages or > > applications. > > My takeaway from Clavis was that it was more about establishing a set > of access controls around keys already present in the keyrings and my > comments about usage/spplication oriented keyrings have been in that > context. While the access control policy, regardless of how it is > implemented, should no doubt incorporate the trust placed in the > individual keys, how that trust is established is a separate issue > from access control as far as I'm concerned. Clavis defined both a mechanism for establishing trust and access control rules. Clavis defined a single Clavis key to establish trust. The Clavis policy rules were signed by the Clavis key. The Clavis policy rules defined the access control. Mimi
> On Feb 28, 2025, at 9:14 AM, Paul Moore <paul@paul-moore.com> wrote: > > On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote: >> On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote: >>> >>> I'd still also like to see some discussion about moving towards the >>> addition of keyrings oriented towards usage instead of limiting >>> ourselves to keyrings that are oriented on the source of the keys. >>> Perhaps I'm missing some important detail which makes this >>> impractical, but it seems like an obvious improvement to me and would >>> go a long way towards solving some of the problems that we typically >>> see with kernel keys. The intent is not to limit ourselves to the source of the key. The main point of Clavis is to allow the end-user to determine what kernel keys they want to trust and for what purpose, irrespective of the originating source (.builtin_trusted, .secondary, .machine, or .platform). If we could go back in time, individual keyrings could be created that are oriented toward usage. The idea for introducing Clavis is to bridge what we have today with kernel keys and allow them to be usage based. >> >> The proliferation of keyrings won't solve the key usage problem for IMA- >> appraisal. IMA-appraisal can be used to verify the kexec image, kernel modules, >> firwmare, etc, but it also verifies file signatures contained in userspace >> packages. > > To be clear I don't think the usage oriented keyring idea will solve > every keyring problem, but it seems like it solves a fair number of > things that I've heard lately. > >> To support the latter case, keyrings would need to be application >> specific. (This version of Clavis doesn't solve the latter key usage for IMA- >> appraisal either.) > > Application specific keyrings are more-or-less what I've been trying > to describe. > >> The keys baked into the kernel are trusted because the kernel itself was signed >> and verified (secure boot). Anyone building a kernel can build a key into the >> kernel image, which establishes a "root of trust". That key can then be used to >> verify and load other keys onto the IMA keyring. > > Sure, I'm not saying that trust isn't important, and that there are > varying levels of trust. My argument is that having additional, > usage/application oriented keyrings which contain links back to keys > imported and stored in the traditional trust oriented keyrings could > neatly solve a number of keyring access control issues. I'm not sure I completely follow this. If a user space application wants to use system kernel keys in this manner, can't this be done today? (I'm not talking about IMA here). The keyctl has both the "link" and "restrict_keyring". Or do you mean take things further with Clavis? Meaning when usage is setup for a key, it is then populated in a new usage based keyring?
On Thu, Feb 27, 2025 at 03:41:18PM -0500, Mimi Zohar wrote: > On Mon, 2025-01-06 at 17:15 +0000, Eric Snowberg wrote: > > > > > On Jan 5, 2025, at 8:40 PM, Paul Moore <paul@paul-moore.com> wrote: > > > > > > On Fri, Jan 3, 2025 at 11:48 PM Paul Moore <paul@paul-moore.com> wrote: > > > > > > > > Regardless, back to Clavis ... reading quickly through the cover > > > > letter again, I do somewhat wonder if this isn't better integrated > > > > into the keyring proper; have you talked to both David and Jarkko > > > > about this? > > > > > > I realize I should probably expand on my thinking a bit, especially > > > since my comment a while regarding LSMs dedicated to enforcing access > > > control on keys is what was given as a reason for making Clavis a LSM. > > > > > > I still stand by my comment from over a year ago that I see no reason > > > why we couldn't support a LSM that enforces access controls on > > > keyrings/keys. What gives me pause with the Clavis LSM is that so > > > much of Clavis is resident in the keyrings themselves, e.g. Clavis > > > policy ACLs and authorization keys, that it really feels like it > > > should be part of the keys subsystem and not a LSM. Yes, existing > > > LSMs do have LSM specific data that resides outside of the LSM and in > > > an object's subsystem, but that is usually limited to security > > > identifiers and similar things, not the LSM's security policy. > > Hi Jarkko, David, > > Both Paul's and my main concerns with this patch set is storing policy in the > keyring. We would appreciate your chiming in here about storing key policy in > the keyring itself. Right so the problem here would be that keyring defines policy for keys? Like in abstract "textbook sense" a policy should not live within in the closure that it dictactes. And the most classic issue would be probably circular dependencies. Theory aside, in practical sense, can you spot an example from the patch set where we could introduce issue by having Clavis as it is? > > thanks, > > Mimi BR, Jarkko
On Thu, Feb 27, 2025 at 05:22:22PM -0500, Paul Moore wrote: > On Thu, Feb 27, 2025 at 3:41 PM Mimi Zohar <zohar@linux.ibm.com> wrote: > > On Mon, 2025-01-06 at 17:15 +0000, Eric Snowberg wrote: > > > > On Jan 5, 2025, at 8:40 PM, Paul Moore <paul@paul-moore.com> wrote: > > > > On Fri, Jan 3, 2025 at 11:48 PM Paul Moore <paul@paul-moore.com> wrote: > > > > > > > > > > Regardless, back to Clavis ... reading quickly through the cover > > > > > letter again, I do somewhat wonder if this isn't better integrated > > > > > into the keyring proper; have you talked to both David and Jarkko > > > > > about this? > > > > > > > > I realize I should probably expand on my thinking a bit, especially > > > > since my comment a while regarding LSMs dedicated to enforcing access > > > > control on keys is what was given as a reason for making Clavis a LSM. > > > > > > > > I still stand by my comment from over a year ago that I see no reason > > > > why we couldn't support a LSM that enforces access controls on > > > > keyrings/keys. What gives me pause with the Clavis LSM is that so > > > > much of Clavis is resident in the keyrings themselves, e.g. Clavis > > > > policy ACLs and authorization keys, that it really feels like it > > > > should be part of the keys subsystem and not a LSM. Yes, existing > > > > LSMs do have LSM specific data that resides outside of the LSM and in > > > > an object's subsystem, but that is usually limited to security > > > > identifiers and similar things, not the LSM's security policy. > > > > Hi Jarkko, David, > > > > Both Paul's and my main concerns with this patch set is storing policy in the > > keyring. We would appreciate your chiming in here about storing key policy in > > the keyring itself. > > I'd still also like to see some discussion about moving towards the > addition of keyrings oriented towards usage instead of limiting > ourselves to keyrings that are oriented on the source of the keys. > Perhaps I'm missing some important detail which makes this > impractical, but it seems like an obvious improvement to me and would > go a long way towards solving some of the problems that we typically > see with kernel keys. I get the theoretical concern but cannot see anything obvious in the patch set that would nail into practical concerns. > > -- > paul-moore.com BR, Jarkko
On Fri, Feb 28, 2025 at 12:19 PM Mimi Zohar <zohar@linux.ibm.com> wrote: > On Fri, 2025-02-28 at 11:14 -0500, Paul Moore wrote: > > On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > > > On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote: ... > Ok, let's go through different scenarios to see if it would scale. > > Scenario 1: Mostly distro signed userspace applications, minimum number of > developer, customer, 3rd party applications. > > Scenario 2: Multiple developer, customer, 3rd party applications, signed by the > same party. > > Scenario 3: extreme case - every application signed by different party. > > With the minimum case, there would probably be a default key or sets of > permissible keys. In the extreme case, the number of keyrings would be > equivalent to the number of application/software packages. Perhaps we're not understanding each other, but my understanding of the above three scenarios is that they are all examples of signed applications where something (likely something in the kernel like IMA) verifies the signature on the application. While there are going to be differing numbers of keys in each of the three scenarios, I believe they would all be on/linked-to the same usage oriented keyring as they all share the same usage: application signatures. > > My takeaway from Clavis was that it was more about establishing a set > > of access controls around keys already present in the keyrings and my > > comments about usage/spplication oriented keyrings have been in that > > context. While the access control policy, regardless of how it is > > implemented, should no doubt incorporate the trust placed in the > > individual keys, how that trust is established is a separate issue > > from access control as far as I'm concerned. > > Clavis defined both a mechanism for establishing trust and access control rules. > > Clavis defined a single Clavis key to establish trust. The Clavis policy rules > were signed by the Clavis key. The Clavis policy rules defined the access > control. Unfortunately I think we're getting a little ambiguous with how we are using the word "trust". Just as "security" can mean different things depending on context, so can "trust" as the qualities we are trusting will vary depending on context. I'll leave it at that for now as I believe we are talking about different things in the paragraphs above. Regardless, I'll also say this regarding Clavis and key/keyring access controls - as implemented, Clavis doesn't look like a LSM to me for the reasons already given. If all of the various keys subsystem maintainers believe it is the Right Thing To Do inside the keys subsystem then it isn't my place to have a say in that. I personally believe that doing the work to support usage oriented keyrings before, or while, implementing a Clavis-like mechanism is the better option, but that is a decision for you and the other key maintainers.
On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg <eric.snowberg@oracle.com> wrote: > > On Feb 28, 2025, at 9:14 AM, Paul Moore <paul@paul-moore.com> wrote: > > On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > >> On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote: > >>> > >>> I'd still also like to see some discussion about moving towards the > >>> addition of keyrings oriented towards usage instead of limiting > >>> ourselves to keyrings that are oriented on the source of the keys. > >>> Perhaps I'm missing some important detail which makes this > >>> impractical, but it seems like an obvious improvement to me and would > >>> go a long way towards solving some of the problems that we typically > >>> see with kernel keys. > > The intent is not to limit ourselves to the source of the key. The main > point of Clavis is to allow the end-user to determine what kernel keys > they want to trust and for what purpose, irrespective of the originating > source (.builtin_trusted, .secondary, .machine, or .platform). If we could > go back in time, individual keyrings could be created that are oriented > toward usage. The idea for introducing Clavis is to bridge what we > have today with kernel keys and allow them to be usage based. While it is unlikely that the current well known keyrings could be removed, I see no reason why new usage oriented keyrings could not be introduced. We've seen far more significant shifts in the kernel over the years.
On Mon, 2025-03-03 at 17:38 -0500, Paul Moore wrote: > On Fri, Feb 28, 2025 at 12:19 PM Mimi Zohar <zohar@linux.ibm.com> wrote: > > On Fri, 2025-02-28 at 11:14 -0500, Paul Moore wrote: > > > On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > > > > On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote: > > ... > > > Ok, let's go through different scenarios to see if it would scale. > > > > Scenario 1: Mostly distro signed userspace applications, minimum number of > > developer, customer, 3rd party applications. > > > > Scenario 2: Multiple developer, customer, 3rd party applications, signed by the > > same party. > > > > Scenario 3: extreme case - every application signed by different party. > > > > With the minimum case, there would probably be a default key or sets of > > permissible keys. In the extreme case, the number of keyrings would be > > equivalent to the number of application/software packages. > > Perhaps we're not understanding each other, but my understanding of > the above three scenarios is that they are all examples of signed > applications where something (likely something in the kernel like IMA) > verifies the signature on the application. While there are going to > be differing numbers of keys in each of the three scenarios, I believe > they would all be on/linked-to the same usage oriented keyring as they > all share the same usage: application signatures. Yes they're all verifying file signatures, but the software packages are from different sources (e.g. distro, chrome), signed by different keys. Only a particular key should be used to verify the file signatures for a particular application. The scenarios, described above, are the ratio of distro/single entity vs. non distro/single entity signed packages, which would correspond to the number of keyrings. Clavis limits key usage based on LSM hooks (e.g. kernel modules, kernel image, firmware, etc). It's a good start, but even this probably is not fine enough granularity. > > > > My takeaway from Clavis was that it was more about establishing a set > > > of access controls around keys already present in the keyrings and my > > > comments about usage/spplication oriented keyrings have been in that > > > context. While the access control policy, regardless of how it is > > > implemented, should no doubt incorporate the trust placed in the > > > individual keys, how that trust is established is a separate issue > > > from access control as far as I'm concerned. > > > > Clavis defined both a mechanism for establishing trust and access control rules. > > > > Clavis defined a single Clavis key to establish trust. The Clavis policy rules > > were signed by the Clavis key. The Clavis policy rules defined the access > > control. > > Unfortunately I think we're getting a little ambiguous with how we are > using the word "trust". Just as "security" can mean different things > depending on context, so can "trust" as the qualities we are trusting > will vary depending on context. I'll leave it at that for now as I > believe we are talking about different things in the paragraphs above. > > Regardless, I'll also say this regarding Clavis and key/keyring access > controls - as implemented, Clavis doesn't look like a LSM to me for > the reasons already given. If all of the various keys subsystem > maintainers believe it is the Right Thing To Do inside the keys > subsystem then it isn't my place to have a say in that. I personally > believe that doing the work to support usage oriented keyrings before, > or while, implementing a Clavis-like mechanism is the better option, > but that is a decision for you and the other key maintainers. "Usage oriented keyrings" similarly implies any key on a particular keyring is acceptable. Without understanding what you mean by "usage oriented keyrings", I would assume it would work initially, but eventually it too will not be fine enough granularity. Mimi
> On Mar 3, 2025, at 3:40 PM, Paul Moore <paul@paul-moore.com> wrote: > > On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg <eric.snowberg@oracle.com> wrote: >>> On Feb 28, 2025, at 9:14 AM, Paul Moore <paul@paul-moore.com> wrote: >>> On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote: >>>> On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote: >>>>> >>>>> I'd still also like to see some discussion about moving towards the >>>>> addition of keyrings oriented towards usage instead of limiting >>>>> ourselves to keyrings that are oriented on the source of the keys. >>>>> Perhaps I'm missing some important detail which makes this >>>>> impractical, but it seems like an obvious improvement to me and would >>>>> go a long way towards solving some of the problems that we typically >>>>> see with kernel keys. >> >> The intent is not to limit ourselves to the source of the key. The main >> point of Clavis is to allow the end-user to determine what kernel keys >> they want to trust and for what purpose, irrespective of the originating >> source (.builtin_trusted, .secondary, .machine, or .platform). If we could >> go back in time, individual keyrings could be created that are oriented >> toward usage. The idea for introducing Clavis is to bridge what we >> have today with kernel keys and allow them to be usage based. > > While it is unlikely that the current well known keyrings could be > removed, I see no reason why new usage oriented keyrings could not be > introduced. We've seen far more significant shifts in the kernel over > the years. Could you further clarify how a usage oriented keyring would work? For example, if a kernel module keyring was added, how would the end-user add keys to it while maintaining a root of trust?
On Mon, Mar 03, 2025 at 05:40:54PM -0500, Paul Moore wrote: > On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg <eric.snowberg@oracle.com> wrote: > > > On Feb 28, 2025, at 9:14 AM, Paul Moore <paul@paul-moore.com> wrote: > > > On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > > >> On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote: > > >>> > > >>> I'd still also like to see some discussion about moving towards the > > >>> addition of keyrings oriented towards usage instead of limiting > > >>> ourselves to keyrings that are oriented on the source of the keys. > > >>> Perhaps I'm missing some important detail which makes this > > >>> impractical, but it seems like an obvious improvement to me and would > > >>> go a long way towards solving some of the problems that we typically > > >>> see with kernel keys. > > > > The intent is not to limit ourselves to the source of the key. The main > > point of Clavis is to allow the end-user to determine what kernel keys > > they want to trust and for what purpose, irrespective of the originating > > source (.builtin_trusted, .secondary, .machine, or .platform). If we could > > go back in time, individual keyrings could be created that are oriented > > toward usage. The idea for introducing Clavis is to bridge what we > > have today with kernel keys and allow them to be usage based. > > While it is unlikely that the current well known keyrings could be > removed, I see no reason why new usage oriented keyrings could not be > introduced. We've seen far more significant shifts in the kernel over > the years. Could we implement such change in a way that these new imaginary (at this point) usage oriented keyrings would be used to create the "legacy" keyrings? > > -- > paul-moore.com > BR, Jarkko
On Tue, Mar 4, 2025 at 7:54 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > On Mon, 2025-03-03 at 17:38 -0500, Paul Moore wrote: > > On Fri, Feb 28, 2025 at 12:19 PM Mimi Zohar <zohar@linux.ibm.com> wrote: > > > On Fri, 2025-02-28 at 11:14 -0500, Paul Moore wrote: > > > > On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > > > > > On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote: > > > > ... > > > > > Ok, let's go through different scenarios to see if it would scale. > > > > > > Scenario 1: Mostly distro signed userspace applications, minimum number of > > > developer, customer, 3rd party applications. > > > > > > Scenario 2: Multiple developer, customer, 3rd party applications, signed by the > > > same party. > > > > > > Scenario 3: extreme case - every application signed by different party. > > > > > > With the minimum case, there would probably be a default key or sets of > > > permissible keys. In the extreme case, the number of keyrings would be > > > equivalent to the number of application/software packages. > > > > Perhaps we're not understanding each other, but my understanding of > > the above three scenarios is that they are all examples of signed > > applications where something (likely something in the kernel like IMA) > > verifies the signature on the application. While there are going to > > be differing numbers of keys in each of the three scenarios, I believe > > they would all be on/linked-to the same usage oriented keyring as they > > all share the same usage: application signatures. > > Yes they're all verifying file signatures, but the software packages are from > different sources (e.g. distro, chrome), signed by different keys. Yep. > Only a > particular key should be used to verify the file signatures for a particular > application. That's definitely one access control policy, but I can also envision a scenario where I have just one keyring for application signatures with multiple keys from multiple vendors. > Clavis limits key usage based on LSM hooks (e.g. kernel modules, kernel image, > firmware, etc). It's a good start, but even this probably is not fine enough > granularity. Which is fine, but like I said earlier, it makes far more sense to me to move towards usage oriented keyrings and then apply whatever additional access control granularity is required to meet a given scenario. It's also worth (re)mentioning that what makes Clavis not-a-LSM in my mind is how it is implemented, not necessarily its security goals. If Clavis were to be implemented in such a way that it only relied on security/LSM blobs and not keys/keyrings it might be more suitable. > > > > My takeaway from Clavis was that it was more about establishing a set > > > > of access controls around keys already present in the keyrings and my > > > > comments about usage/spplication oriented keyrings have been in that > > > > context. While the access control policy, regardless of how it is > > > > implemented, should no doubt incorporate the trust placed in the > > > > individual keys, how that trust is established is a separate issue > > > > from access control as far as I'm concerned. > > > > > > Clavis defined both a mechanism for establishing trust and access control rules. > > > > > > Clavis defined a single Clavis key to establish trust. The Clavis policy rules > > > were signed by the Clavis key. The Clavis policy rules defined the access > > > control. > > > > Unfortunately I think we're getting a little ambiguous with how we are > > using the word "trust". Just as "security" can mean different things > > depending on context, so can "trust" as the qualities we are trusting > > will vary depending on context. I'll leave it at that for now as I > > believe we are talking about different things in the paragraphs above. > > > > Regardless, I'll also say this regarding Clavis and key/keyring access > > controls - as implemented, Clavis doesn't look like a LSM to me for > > the reasons already given. If all of the various keys subsystem > > maintainers believe it is the Right Thing To Do inside the keys > > subsystem then it isn't my place to have a say in that. I personally > > believe that doing the work to support usage oriented keyrings before, > > or while, implementing a Clavis-like mechanism is the better option, > > but that is a decision for you and the other key maintainers. > > "Usage oriented keyrings" similarly implies any key on a particular keyring is > acceptable. Yep. > Without understanding what you mean by "usage oriented keyrings", I > would assume it would work initially, but eventually it too will not be fine > enough granularity. It all depends on what your goals are, but like I said above, it really seems to me like this is a good first step which can be followed up with additional granularity.
On Tue, Mar 4, 2025 at 9:47 AM Eric Snowberg <eric.snowberg@oracle.com> wrote: > > On Mar 3, 2025, at 3:40 PM, Paul Moore <paul@paul-moore.com> wrote: > > On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg <eric.snowberg@oracle.com> wrote: > >>> On Feb 28, 2025, at 9:14 AM, Paul Moore <paul@paul-moore.com> wrote: > >>> On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > >>>> On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote: > >>>>> > >>>>> I'd still also like to see some discussion about moving towards the > >>>>> addition of keyrings oriented towards usage instead of limiting > >>>>> ourselves to keyrings that are oriented on the source of the keys. > >>>>> Perhaps I'm missing some important detail which makes this > >>>>> impractical, but it seems like an obvious improvement to me and would > >>>>> go a long way towards solving some of the problems that we typically > >>>>> see with kernel keys. > >> > >> The intent is not to limit ourselves to the source of the key. The main > >> point of Clavis is to allow the end-user to determine what kernel keys > >> they want to trust and for what purpose, irrespective of the originating > >> source (.builtin_trusted, .secondary, .machine, or .platform). If we could > >> go back in time, individual keyrings could be created that are oriented > >> toward usage. The idea for introducing Clavis is to bridge what we > >> have today with kernel keys and allow them to be usage based. > > > > While it is unlikely that the current well known keyrings could be > > removed, I see no reason why new usage oriented keyrings could not be > > introduced. We've seen far more significant shifts in the kernel over > > the years. > > Could you further clarify how a usage oriented keyring would work? For > example, if a kernel module keyring was added, how would the end-user > add keys to it while maintaining a root of trust? Consider it an exercise left to the reader :) I imagine there are different ways one could do that, either using traditional user/group/capability permissions and/or LSM permissions, it would depend on the environment and the security goals of the overall system.
On Tue, Mar 4, 2025 at 5:25 PM Jarkko Sakkinen <jarkko@kernel.org> wrote: > On Mon, Mar 03, 2025 at 05:40:54PM -0500, Paul Moore wrote: > > On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg <eric.snowberg@oracle.com> wrote: > > > > On Feb 28, 2025, at 9:14 AM, Paul Moore <paul@paul-moore.com> wrote: > > > > On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > > > >> On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote: > > > >>> > > > >>> I'd still also like to see some discussion about moving towards the > > > >>> addition of keyrings oriented towards usage instead of limiting > > > >>> ourselves to keyrings that are oriented on the source of the keys. > > > >>> Perhaps I'm missing some important detail which makes this > > > >>> impractical, but it seems like an obvious improvement to me and would > > > >>> go a long way towards solving some of the problems that we typically > > > >>> see with kernel keys. > > > > > > The intent is not to limit ourselves to the source of the key. The main > > > point of Clavis is to allow the end-user to determine what kernel keys > > > they want to trust and for what purpose, irrespective of the originating > > > source (.builtin_trusted, .secondary, .machine, or .platform). If we could > > > go back in time, individual keyrings could be created that are oriented > > > toward usage. The idea for introducing Clavis is to bridge what we > > > have today with kernel keys and allow them to be usage based. > > > > While it is unlikely that the current well known keyrings could be > > removed, I see no reason why new usage oriented keyrings could not be > > introduced. We've seen far more significant shifts in the kernel over > > the years. > > Could we implement such change in a way that these new imaginary > (at this point) usage oriented keyrings would be used to create > the "legacy" keyrings? I think it would be easier for them to coexist so that one could have an easier migration. It's possible that even once everything was migrated to the new usage oriented keyrings it would still make sense to keep the existing keyrings in place and always link keys from there to the newer usage keyrings.
On Tue, Mar 04, 2025 at 07:25:13PM -0500, Paul Moore wrote: > On Tue, Mar 4, 2025 at 5:25 PM Jarkko Sakkinen <jarkko@kernel.org> wrote: > > On Mon, Mar 03, 2025 at 05:40:54PM -0500, Paul Moore wrote: > > > On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg <eric.snowberg@oracle.com> wrote: > > > > > On Feb 28, 2025, at 9:14 AM, Paul Moore <paul@paul-moore.com> wrote: > > > > > On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > > > > >> On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote: > > > > >>> > > > > >>> I'd still also like to see some discussion about moving towards the > > > > >>> addition of keyrings oriented towards usage instead of limiting > > > > >>> ourselves to keyrings that are oriented on the source of the keys. > > > > >>> Perhaps I'm missing some important detail which makes this > > > > >>> impractical, but it seems like an obvious improvement to me and would > > > > >>> go a long way towards solving some of the problems that we typically > > > > >>> see with kernel keys. > > > > > > > > The intent is not to limit ourselves to the source of the key. The main > > > > point of Clavis is to allow the end-user to determine what kernel keys > > > > they want to trust and for what purpose, irrespective of the originating > > > > source (.builtin_trusted, .secondary, .machine, or .platform). If we could > > > > go back in time, individual keyrings could be created that are oriented > > > > toward usage. The idea for introducing Clavis is to bridge what we > > > > have today with kernel keys and allow them to be usage based. > > > > > > While it is unlikely that the current well known keyrings could be > > > removed, I see no reason why new usage oriented keyrings could not be > > > introduced. We've seen far more significant shifts in the kernel over > > > the years. > > > > Could we implement such change in a way that these new imaginary > > (at this point) usage oriented keyrings would be used to create > > the "legacy" keyrings? > > I think it would be easier for them to coexist so that one could have > an easier migration. It's possible that even once everything was > migrated to the new usage oriented keyrings it would still make sense > to keep the existing keyrings in place and always link keys from there > to the newer usage keyrings. OK, so here I agree and disagree: 1. It probably does not port everything. 2. Still, we need to be sure that "can be done" condition is satisfied for the sake of robustness. > > -- > paul-moore.com > BR, Jarkko
On Tue, 2025-03-04 at 19:19 -0500, Paul Moore wrote: > On Tue, Mar 4, 2025 at 7:54 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > > On Mon, 2025-03-03 at 17:38 -0500, Paul Moore wrote: > > > On Fri, Feb 28, 2025 at 12:19 PM Mimi Zohar <zohar@linux.ibm.com> wrote: > > > > On Fri, 2025-02-28 at 11:14 -0500, Paul Moore wrote: > > > > > On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > > > > > > On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote: > > > > > > ... > > > > > > > Ok, let's go through different scenarios to see if it would scale. > > > > > > > > Scenario 1: Mostly distro signed userspace applications, minimum number of > > > > developer, customer, 3rd party applications. > > > > > > > > Scenario 2: Multiple developer, customer, 3rd party applications, signed by the > > > > same party. > > > > > > > > Scenario 3: extreme case - every application signed by different party. > > > > > > > > With the minimum case, there would probably be a default key or sets of > > > > permissible keys. In the extreme case, the number of keyrings would be > > > > equivalent to the number of application/software packages. > > > > > > Perhaps we're not understanding each other, but my understanding of > > > the above three scenarios is that they are all examples of signed > > > applications where something (likely something in the kernel like IMA) > > > verifies the signature on the application. While there are going to > > > be differing numbers of keys in each of the three scenarios, I believe > > > they would all be on/linked-to the same usage oriented keyring as they > > > all share the same usage: application signatures. > > > > Yes they're all verifying file signatures, but the software packages are from > > different sources (e.g. distro, chrome), signed by different keys. > > Yep. > > > Only a > > particular key should be used to verify the file signatures for a particular > > application. > > That's definitely one access control policy, but I can also envision a > scenario where I have just one keyring for application signatures with > multiple keys from multiple vendors. Having a single keyring with keys from multiple software vendors is the status quo. > > > Clavis limits key usage based on LSM hooks (e.g. kernel modules, kernel image, > > firmware, etc). It's a good start, but even this probably is not fine enough > > granularity. > > Which is fine, but like I said earlier, it makes far more sense to me > to move towards usage oriented keyrings and then apply whatever > additional access control granularity is required to meet a given > scenario. Since you didn't agree with my example of "usage oriented keyrings", please provide an example. > > It's also worth (re)mentioning that what makes Clavis not-a-LSM in my > mind is how it is implemented, not necessarily its security goals. If > Clavis were to be implemented in such a way that it only relied on > security/LSM blobs and not keys/keyrings it might be more suitable. > > > > > > My takeaway from Clavis was that it was more about establishing a set > > > > > of access controls around keys already present in the keyrings and my > > > > > comments about usage/spplication oriented keyrings have been in that > > > > > context. While the access control policy, regardless of how it is > > > > > implemented, should no doubt incorporate the trust placed in the > > > > > individual keys, how that trust is established is a separate issue > > > > > from access control as far as I'm concerned. > > > > > > > > Clavis defined both a mechanism for establishing trust and access control rules. > > > > > > > > Clavis defined a single Clavis key to establish trust. The Clavis policy rules > > > > were signed by the Clavis key. The Clavis policy rules defined the access > > > > control. > > > > > > Unfortunately I think we're getting a little ambiguous with how we are > > > using the word "trust". Just as "security" can mean different things > > > depending on context, so can "trust" as the qualities we are trusting > > > will vary depending on context. I'll leave it at that for now as I > > > believe we are talking about different things in the paragraphs above. > > > > > > Regardless, I'll also say this regarding Clavis and key/keyring access > > > controls - as implemented, Clavis doesn't look like a LSM to me for > > > the reasons already given. If all of the various keys subsystem > > > maintainers believe it is the Right Thing To Do inside the keys > > > subsystem then it isn't my place to have a say in that. I personally > > > believe that doing the work to support usage oriented keyrings before, > > > or while, implementing a Clavis-like mechanism is the better option, > > > but that is a decision for you and the other key maintainers. > > > > "Usage oriented keyrings" similarly implies any key on a particular keyring is > > acceptable. > > Yep. > > > Without understanding what you mean by "usage oriented keyrings", I > > would assume it would work initially, but eventually it too will not be fine > > enough granularity. > > It all depends on what your goals are, but like I said above, it > really seems to me like this is a good first step which can be > followed up with additional granularity. Without a concrete example of "usage oriented keyrings", it's hard to understand why "additional" granularity should be deferred. From my perspective, "additional" granularity is the main issue. Mimi
On Tue, Mar 4, 2025 at 8:50 PM Mimi Zohar <zohar@linux.ibm.com> wrote: > On Tue, 2025-03-04 at 19:19 -0500, Paul Moore wrote: > > On Tue, Mar 4, 2025 at 7:54 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > > > On Mon, 2025-03-03 at 17:38 -0500, Paul Moore wrote: > > > > On Fri, Feb 28, 2025 at 12:19 PM Mimi Zohar <zohar@linux.ibm.com> wrote: > > > > > On Fri, 2025-02-28 at 11:14 -0500, Paul Moore wrote: > > > > > > On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > > > > > > > On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote: > > > > > > > > ... > > > > > > > > > Ok, let's go through different scenarios to see if it would scale. > > > > > > > > > > Scenario 1: Mostly distro signed userspace applications, minimum number of > > > > > developer, customer, 3rd party applications. > > > > > > > > > > Scenario 2: Multiple developer, customer, 3rd party applications, signed by the > > > > > same party. > > > > > > > > > > Scenario 3: extreme case - every application signed by different party. > > > > > > > > > > With the minimum case, there would probably be a default key or sets of > > > > > permissible keys. In the extreme case, the number of keyrings would be > > > > > equivalent to the number of application/software packages. > > > > > > > > Perhaps we're not understanding each other, but my understanding of > > > > the above three scenarios is that they are all examples of signed > > > > applications where something (likely something in the kernel like IMA) > > > > verifies the signature on the application. While there are going to > > > > be differing numbers of keys in each of the three scenarios, I believe > > > > they would all be on/linked-to the same usage oriented keyring as they > > > > all share the same usage: application signatures. > > > > > > Yes they're all verifying file signatures, but the software packages are from > > > different sources (e.g. distro, chrome), signed by different keys. > > > > Yep. > > > > > Only a > > > particular key should be used to verify the file signatures for a particular > > > application. > > > > That's definitely one access control policy, but I can also envision a > > scenario where I have just one keyring for application signatures with > > multiple keys from multiple vendors. > > Having a single keyring with keys from multiple software vendors is the status > quo. A single keyring with keys from multiple vendors does happen today yes, but there is no separation based on how those keys are used, e.g. separate application signature and kernel module signature keyrings. > > > Clavis limits key usage based on LSM hooks (e.g. kernel modules, kernel image, > > > firmware, etc). It's a good start, but even this probably is not fine enough > > > granularity. > > > > Which is fine, but like I said earlier, it makes far more sense to me > > to move towards usage oriented keyrings and then apply whatever > > additional access control granularity is required to meet a given > > scenario. > > Since you didn't agree with my example of "usage oriented keyrings", please > provide an example. I have.
On Tue, 2025-03-04 at 21:09 -0500, Paul Moore wrote: > On Tue, Mar 4, 2025 at 8:50 PM Mimi Zohar <zohar@linux.ibm.com> wrote: > > On Tue, 2025-03-04 at 19:19 -0500, Paul Moore wrote: > > > On Tue, Mar 4, 2025 at 7:54 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > > > > On Mon, 2025-03-03 at 17:38 -0500, Paul Moore wrote: > > > > > On Fri, Feb 28, 2025 at 12:19 PM Mimi Zohar <zohar@linux.ibm.com> wrote: > > > > > > On Fri, 2025-02-28 at 11:14 -0500, Paul Moore wrote: > > > > > > > On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > > > > > > > > On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote: > > > > > > > > > > ... > > > > > > > > > > > Ok, let's go through different scenarios to see if it would scale. > > > > > > > > > > > > Scenario 1: Mostly distro signed userspace applications, minimum number of > > > > > > developer, customer, 3rd party applications. > > > > > > > > > > > > Scenario 2: Multiple developer, customer, 3rd party applications, signed by the > > > > > > same party. > > > > > > > > > > > > Scenario 3: extreme case - every application signed by different party. > > > > > > > > > > > > With the minimum case, there would probably be a default key or sets of > > > > > > permissible keys. In the extreme case, the number of keyrings would be > > > > > > equivalent to the number of application/software packages. > > > > > > > > > > Perhaps we're not understanding each other, but my understanding of > > > > > the above three scenarios is that they are all examples of signed > > > > > applications where something (likely something in the kernel like IMA) > > > > > verifies the signature on the application. While there are going to > > > > > be differing numbers of keys in each of the three scenarios, I believe > > > > > they would all be on/linked-to the same usage oriented keyring as they > > > > > all share the same usage: application signatures. > > > > > > > > Yes they're all verifying file signatures, but the software packages are from > > > > different sources (e.g. distro, chrome), signed by different keys. > > > > > > Yep. > > > > > > > Only a > > > > particular key should be used to verify the file signatures for a particular > > > > application. > > > > > > That's definitely one access control policy, but I can also envision a > > > scenario where I have just one keyring for application signatures with > > > multiple keys from multiple vendors. > > > > Having a single keyring with keys from multiple software vendors is the status > > quo. > > A single keyring with keys from multiple vendors does happen today > yes, but there is no separation based on how those keys are used, e.g. > separate application signature and kernel module signature keyrings. As soon as you add multiple vendors keys on the kernel module signature keyring, you'll need finer grained access control. Mimi
On Tue, Mar 4, 2025 at 9:20 PM Mimi Zohar <zohar@linux.ibm.com> wrote: > On Tue, 2025-03-04 at 21:09 -0500, Paul Moore wrote: > > On Tue, Mar 4, 2025 at 8:50 PM Mimi Zohar <zohar@linux.ibm.com> wrote: > > > On Tue, 2025-03-04 at 19:19 -0500, Paul Moore wrote: > > > > On Tue, Mar 4, 2025 at 7:54 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > > > > > On Mon, 2025-03-03 at 17:38 -0500, Paul Moore wrote: > > > > > > On Fri, Feb 28, 2025 at 12:19 PM Mimi Zohar <zohar@linux.ibm.com> wrote: > > > > > > > On Fri, 2025-02-28 at 11:14 -0500, Paul Moore wrote: > > > > > > > > On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > > > > > > > > > On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote: > > > > > > > > > > > > ... > > > > > > > > > > > > > Ok, let's go through different scenarios to see if it would scale. > > > > > > > > > > > > > > Scenario 1: Mostly distro signed userspace applications, minimum number of > > > > > > > developer, customer, 3rd party applications. > > > > > > > > > > > > > > Scenario 2: Multiple developer, customer, 3rd party applications, signed by the > > > > > > > same party. > > > > > > > > > > > > > > Scenario 3: extreme case - every application signed by different party. > > > > > > > > > > > > > > With the minimum case, there would probably be a default key or sets of > > > > > > > permissible keys. In the extreme case, the number of keyrings would be > > > > > > > equivalent to the number of application/software packages. > > > > > > > > > > > > Perhaps we're not understanding each other, but my understanding of > > > > > > the above three scenarios is that they are all examples of signed > > > > > > applications where something (likely something in the kernel like IMA) > > > > > > verifies the signature on the application. While there are going to > > > > > > be differing numbers of keys in each of the three scenarios, I believe > > > > > > they would all be on/linked-to the same usage oriented keyring as they > > > > > > all share the same usage: application signatures. > > > > > > > > > > Yes they're all verifying file signatures, but the software packages are from > > > > > different sources (e.g. distro, chrome), signed by different keys. > > > > > > > > Yep. > > > > > > > > > Only a > > > > > particular key should be used to verify the file signatures for a particular > > > > > application. > > > > > > > > That's definitely one access control policy, but I can also envision a > > > > scenario where I have just one keyring for application signatures with > > > > multiple keys from multiple vendors. > > > > > > Having a single keyring with keys from multiple software vendors is the status > > > quo. > > > > A single keyring with keys from multiple vendors does happen today > > yes, but there is no separation based on how those keys are used, e.g. > > separate application signature and kernel module signature keyrings. > > As soon as you add multiple vendors keys on the kernel module signature keyring, > you'll need finer grained access control. Maybe. It depends on your security policy, some solutions might be okay with keyring level access control granularity, others may want finer grained control.
> On Mar 4, 2025, at 5:23 PM, Paul Moore <paul@paul-moore.com> wrote: > > On Tue, Mar 4, 2025 at 9:47 AM Eric Snowberg <eric.snowberg@oracle.com> wrote: >>> On Mar 3, 2025, at 3:40 PM, Paul Moore <paul@paul-moore.com> wrote: >>> On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg <eric.snowberg@oracle.com> wrote: >>>>> On Feb 28, 2025, at 9:14 AM, Paul Moore <paul@paul-moore.com> wrote: >>>>> On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote: >>>>>> On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote: >>>>>>> >>>>>>> I'd still also like to see some discussion about moving towards the >>>>>>> addition of keyrings oriented towards usage instead of limiting >>>>>>> ourselves to keyrings that are oriented on the source of the keys. >>>>>>> Perhaps I'm missing some important detail which makes this >>>>>>> impractical, but it seems like an obvious improvement to me and would >>>>>>> go a long way towards solving some of the problems that we typically >>>>>>> see with kernel keys. >>>> >>>> The intent is not to limit ourselves to the source of the key. The main >>>> point of Clavis is to allow the end-user to determine what kernel keys >>>> they want to trust and for what purpose, irrespective of the originating >>>> source (.builtin_trusted, .secondary, .machine, or .platform). If we could >>>> go back in time, individual keyrings could be created that are oriented >>>> toward usage. The idea for introducing Clavis is to bridge what we >>>> have today with kernel keys and allow them to be usage based. >>> >>> While it is unlikely that the current well known keyrings could be >>> removed, I see no reason why new usage oriented keyrings could not be >>> introduced. We've seen far more significant shifts in the kernel over >>> the years. >> >> Could you further clarify how a usage oriented keyring would work? For >> example, if a kernel module keyring was added, how would the end-user >> add keys to it while maintaining a root of trust? > > Consider it an exercise left to the reader :) > > I imagine there are different ways one could do that, either using > traditional user/group/capability permissions and/or LSM permissions, > it would depend on the environment and the security goals of the > overall system. These keys are used by the Lockdown LSM to provide signature validation. I realize the contents that follow in this paragraph is outside the boundary of mainline kernel code. Every distro that wants their shim signed must explain how their kernel enforces lockdown mode. The minimum requirement is lockdown in integrity mode. Also, the expectation is lockdown enforcement continues on through a kexec. When in lockdown integrity mode, features that allow the kernel to be modified at runtime are disabled. How would what you have suggested above adhere to these goals? The point of the Clavis LSM is to use the root of trust provided to the kernel prior to it booting. This maintains the lockdown integrity goals, while also giving the end-user the ability to determine how kernel keys are used.
On Wed, Mar 5, 2025 at 4:30 PM Eric Snowberg <eric.snowberg@oracle.com> wrote: > > On Mar 4, 2025, at 5:23 PM, Paul Moore <paul@paul-moore.com> wrote: > > On Tue, Mar 4, 2025 at 9:47 AM Eric Snowberg <eric.snowberg@oracle.com> wrote: > >>> On Mar 3, 2025, at 3:40 PM, Paul Moore <paul@paul-moore.com> wrote: > >>> On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg <eric.snowberg@oracle.com> wrote: > >>>>> On Feb 28, 2025, at 9:14 AM, Paul Moore <paul@paul-moore.com> wrote: > >>>>> On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote: > >>>>>> On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote: > >>>>>>> > >>>>>>> I'd still also like to see some discussion about moving towards the > >>>>>>> addition of keyrings oriented towards usage instead of limiting > >>>>>>> ourselves to keyrings that are oriented on the source of the keys. > >>>>>>> Perhaps I'm missing some important detail which makes this > >>>>>>> impractical, but it seems like an obvious improvement to me and would > >>>>>>> go a long way towards solving some of the problems that we typically > >>>>>>> see with kernel keys. > >>>> > >>>> The intent is not to limit ourselves to the source of the key. The main > >>>> point of Clavis is to allow the end-user to determine what kernel keys > >>>> they want to trust and for what purpose, irrespective of the originating > >>>> source (.builtin_trusted, .secondary, .machine, or .platform). If we could > >>>> go back in time, individual keyrings could be created that are oriented > >>>> toward usage. The idea for introducing Clavis is to bridge what we > >>>> have today with kernel keys and allow them to be usage based. > >>> > >>> While it is unlikely that the current well known keyrings could be > >>> removed, I see no reason why new usage oriented keyrings could not be > >>> introduced. We've seen far more significant shifts in the kernel over > >>> the years. > >> > >> Could you further clarify how a usage oriented keyring would work? For > >> example, if a kernel module keyring was added, how would the end-user > >> add keys to it while maintaining a root of trust? > > > > Consider it an exercise left to the reader :) > > > > I imagine there are different ways one could do that, either using > > traditional user/group/capability permissions and/or LSM permissions, > > it would depend on the environment and the security goals of the > > overall system. > > These keys are used by the Lockdown LSM to provide signature > validation. > > I realize the contents that follow in this paragraph is outside the > boundary of mainline kernel code. Every distro that wants their > shim signed must explain how their kernel enforces lockdown > mode. The minimum requirement is lockdown in integrity mode. > Also, the expectation is lockdown enforcement continues on > through a kexec. I personally find it very amusing the UEFI Secure Boot shim is reliant on an unmaintained and only marginally supported LSM, Lockdown. Has anyone recently verified that Lockdown's protections are still intact and comprehensive enough to be worthwhile? Sorry, this is a bit of a digression, but since you were the one to bring up Lockdown I thought it would be important to mention that I don't have much faith that it is still working to the same level as it originally was intended. I have a TODO list item to draft a policy around deprecating unmaintained LSMs after an extended period of time, and once that is in place if we don't have a qualified maintainer for Lockdown it will likely fall into the deprecation process (whatever that may be). > When in lockdown integrity mode, features that allow the kernel > to be modified at runtime are disabled. How would what you have > suggested above adhere to these goals? For starters, verify that Lockdown is still comprehensive enough to satisfy these requirements on a modern Linux kernel. After that has been done, find someone with some kernel experience to step up and maintain Lockdown. Finally, put a mechanism in place so that someone/something is regularly evaluating changes in the upstream kernel to ensure that Lockdown is still able to achieve its security goals. After all that, then you can start worrying about keys. > The point of the Clavis LSM is to use the root of trust provided to > the kernel prior to it booting. This maintains the lockdown integrity > goals, while also giving the end-user the ability to determine how > kernel keys are used.
> On Mar 5, 2025, at 6:12 PM, Paul Moore <paul@paul-moore.com> wrote: > > On Wed, Mar 5, 2025 at 4:30 PM Eric Snowberg <eric.snowberg@oracle.com> wrote: >>> On Mar 4, 2025, at 5:23 PM, Paul Moore <paul@paul-moore.com> wrote: >>> On Tue, Mar 4, 2025 at 9:47 AM Eric Snowberg <eric.snowberg@oracle.com> wrote: >>>>> On Mar 3, 2025, at 3:40 PM, Paul Moore <paul@paul-moore.com> wrote: >>>>> On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg <eric.snowberg@oracle.com> wrote: >>>>>>> On Feb 28, 2025, at 9:14 AM, Paul Moore <paul@paul-moore.com> wrote: >>>>>>> On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote: >>>>>>>> On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote: >>>>>>>>> >>>>>>>>> I'd still also like to see some discussion about moving towards the >>>>>>>>> addition of keyrings oriented towards usage instead of limiting >>>>>>>>> ourselves to keyrings that are oriented on the source of the keys. >>>>>>>>> Perhaps I'm missing some important detail which makes this >>>>>>>>> impractical, but it seems like an obvious improvement to me and would >>>>>>>>> go a long way towards solving some of the problems that we typically >>>>>>>>> see with kernel keys. >>>>>> >>>>>> The intent is not to limit ourselves to the source of the key. The main >>>>>> point of Clavis is to allow the end-user to determine what kernel keys >>>>>> they want to trust and for what purpose, irrespective of the originating >>>>>> source (.builtin_trusted, .secondary, .machine, or .platform). If we could >>>>>> go back in time, individual keyrings could be created that are oriented >>>>>> toward usage. The idea for introducing Clavis is to bridge what we >>>>>> have today with kernel keys and allow them to be usage based. >>>>> >>>>> While it is unlikely that the current well known keyrings could be >>>>> removed, I see no reason why new usage oriented keyrings could not be >>>>> introduced. We've seen far more significant shifts in the kernel over >>>>> the years. >>>> >>>> Could you further clarify how a usage oriented keyring would work? For >>>> example, if a kernel module keyring was added, how would the end-user >>>> add keys to it while maintaining a root of trust? >>> >>> Consider it an exercise left to the reader :) >>> >>> I imagine there are different ways one could do that, either using >>> traditional user/group/capability permissions and/or LSM permissions, >>> it would depend on the environment and the security goals of the >>> overall system. >> >> These keys are used by the Lockdown LSM to provide signature >> validation. >> >> I realize the contents that follow in this paragraph is outside the >> boundary of mainline kernel code. Every distro that wants their >> shim signed must explain how their kernel enforces lockdown >> mode. The minimum requirement is lockdown in integrity mode. >> Also, the expectation is lockdown enforcement continues on >> through a kexec. > > I personally find it very amusing the UEFI Secure Boot shim is reliant > on an unmaintained and only marginally supported LSM, Lockdown. Has > anyone recently verified that Lockdown's protections are still intact > and comprehensive enough to be worthwhile? Sorry, this is a bit of a > digression, but since you were the one to bring up Lockdown I thought > it would be important to mention that I don't have much faith that it > is still working to the same level as it originally was intended. I > have a TODO list item to draft a policy around deprecating > unmaintained LSMs after an extended period of time, and once that is > in place if we don't have a qualified maintainer for Lockdown it will > likely fall into the deprecation process (whatever that may be). Does this mean Microsoft will begin signing shims in the future without the lockdown requirement?
On March 6, 2025 5:29:36 PM Eric Snowberg <eric.snowberg@oracle.com> wrote: >> On Mar 5, 2025, at 6:12 PM, Paul Moore <paul@paul-moore.com> wrote: >> >> On Wed, Mar 5, 2025 at 4:30 PM Eric Snowberg <eric.snowberg@oracle.com> wrote: >>>> On Mar 4, 2025, at 5:23 PM, Paul Moore <paul@paul-moore.com> wrote: >>>> On Tue, Mar 4, 2025 at 9:47 AM Eric Snowberg <eric.snowberg@oracle.com> wrote: >>>>>> On Mar 3, 2025, at 3:40 PM, Paul Moore <paul@paul-moore.com> wrote: >>>>>> On Fri, Feb 28, 2025 at 12:52 PM Eric Snowberg <eric.snowberg@oracle.com> >>>>>> wrote: >>>>>>>> On Feb 28, 2025, at 9:14 AM, Paul Moore <paul@paul-moore.com> wrote: >>>>>>>> On Fri, Feb 28, 2025 at 9:09 AM Mimi Zohar <zohar@linux.ibm.com> wrote: >>>>>>>>> On Thu, 2025-02-27 at 17:22 -0500, Paul Moore wrote: >>>>>>>>>> >>>>>>>>>> I'd still also like to see some discussion about moving towards the >>>>>>>>>> addition of keyrings oriented towards usage instead of limiting >>>>>>>>>> ourselves to keyrings that are oriented on the source of the keys. >>>>>>>>>> Perhaps I'm missing some important detail which makes this >>>>>>>>>> impractical, but it seems like an obvious improvement to me and would >>>>>>>>>> go a long way towards solving some of the problems that we typically >>>>>>>>>> see with kernel keys. >>>>>>> >>>>>>> The intent is not to limit ourselves to the source of the key. The main >>>>>>> point of Clavis is to allow the end-user to determine what kernel keys >>>>>>> they want to trust and for what purpose, irrespective of the originating >>>>>>> source (.builtin_trusted, .secondary, .machine, or .platform). If we could >>>>>>> go back in time, individual keyrings could be created that are oriented >>>>>>> toward usage. The idea for introducing Clavis is to bridge what we >>>>>>> have today with kernel keys and allow them to be usage based. >>>>>> >>>>>> While it is unlikely that the current well known keyrings could be >>>>>> removed, I see no reason why new usage oriented keyrings could not be >>>>>> introduced. We've seen far more significant shifts in the kernel over >>>>>> the years. >>>>> >>>>> Could you further clarify how a usage oriented keyring would work? For >>>>> example, if a kernel module keyring was added, how would the end-user >>>>> add keys to it while maintaining a root of trust? >>>> >>>> Consider it an exercise left to the reader :) >>>> >>>> I imagine there are different ways one could do that, either using >>>> traditional user/group/capability permissions and/or LSM permissions, >>>> it would depend on the environment and the security goals of the >>>> overall system. >>> >>> These keys are used by the Lockdown LSM to provide signature >>> validation. >>> >>> I realize the contents that follow in this paragraph is outside the >>> boundary of mainline kernel code. Every distro that wants their >>> shim signed must explain how their kernel enforces lockdown >>> mode. The minimum requirement is lockdown in integrity mode. >>> Also, the expectation is lockdown enforcement continues on >>> through a kexec. >> >> I personally find it very amusing the UEFI Secure Boot shim is reliant >> on an unmaintained and only marginally supported LSM, Lockdown. Has >> anyone recently verified that Lockdown's protections are still intact >> and comprehensive enough to be worthwhile? Sorry, this is a bit of a >> digression, but since you were the one to bring up Lockdown I thought >> it would be important to mention that I don't have much faith that it >> is still working to the same level as it originally was intended. I >> have a TODO list item to draft a policy around deprecating >> unmaintained LSMs after an extended period of time, and once that is >> in place if we don't have a qualified maintainer for Lockdown it will >> likely fall into the deprecation process (whatever that may be). > > Does this mean Microsoft will begin signing shims in the future without > the lockdown requirement? That's not a question I can answer, you'll need to discuss that with the UEFI SB people. -- paul-moore.com