| Message ID | 20210114151909.2344974-10-mic@digikod.net (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | Enable root to update the blacklist keyring | expand |
Hi Mickaël, On Thu, 2021-01-14 at 16:19 +0100, Mickaël Salaün wrote: > From: Mickaël Salaün <mic@linux.microsoft.com> > > Add a kernel option SYSTEM_BLACKLIST_AUTH_UPDATE to enable the root user > to dynamically add new keys to the blacklist keyring. This enables to > invalidate new certificates, either from being loaded in a keyring, or > from being trusted in a PKCS#7 certificate chain. This also enables to > add new file hashes to be denied by the integrity infrastructure. > > Being able to untrust a certificate which could have normaly been > trusted is a sensitive operation. This is why adding new hashes to the > blacklist keyring is only allowed when these hashes are signed and > vouched by the builtin trusted keyring. A blacklist hash is stored as a > key description. The PKCS#7 signature of this description must be > provided as the key payload. > > Marking a certificate as untrusted should be enforced while the system > is running. It is then forbiden to remove such blacklist keys. > > Update blacklist keyring and blacklist key access rights: > * allows the root user to search for a specific blacklisted hash, which > make sense because the descriptions are already viewable; > * forbids key update; > * restricts kernel rights on the blacklist keyring to align with the > root user rights. > > See the help in tools/certs/print-cert-tbs-hash.sh provided by a > following commit. The design looks good. I'm hoping to review/test at least this patch next week. thanks, Mimi
On Thu, Jan 14, 2021 at 04:19:08PM +0100, Mickaël Salaün wrote: > From: Mickaël Salaün <mic@linux.microsoft.com> > > Add a kernel option SYSTEM_BLACKLIST_AUTH_UPDATE to enable the root user > to dynamically add new keys to the blacklist keyring. This enables to > invalidate new certificates, either from being loaded in a keyring, or > from being trusted in a PKCS#7 certificate chain. This also enables to > add new file hashes to be denied by the integrity infrastructure. > > Being able to untrust a certificate which could have normaly been > trusted is a sensitive operation. This is why adding new hashes to the > blacklist keyring is only allowed when these hashes are signed and > vouched by the builtin trusted keyring. A blacklist hash is stored as a > key description. The PKCS#7 signature of this description must be > provided as the key payload. > > Marking a certificate as untrusted should be enforced while the system > is running. It is then forbiden to remove such blacklist keys. > > Update blacklist keyring and blacklist key access rights: > * allows the root user to search for a specific blacklisted hash, which > make sense because the descriptions are already viewable; > * forbids key update; > * restricts kernel rights on the blacklist keyring to align with the > root user rights. > > See the help in tools/certs/print-cert-tbs-hash.sh provided by a > following commit. Please re-order patches in a way that print-cert-tbs-hash.sh is available before this. That way we get rid of this useless remark. > Cc: David Howells <dhowells@redhat.com> > Cc: David Woodhouse <dwmw2@infradead.org> > Signed-off-by: Mickaël Salaün <mic@linux.microsoft.com> /Jarkko
On 20/01/2021 06:23, Jarkko Sakkinen wrote: > On Thu, Jan 14, 2021 at 04:19:08PM +0100, Mickaël Salaün wrote: >> From: Mickaël Salaün <mic@linux.microsoft.com> >> >> Add a kernel option SYSTEM_BLACKLIST_AUTH_UPDATE to enable the root user >> to dynamically add new keys to the blacklist keyring. This enables to >> invalidate new certificates, either from being loaded in a keyring, or >> from being trusted in a PKCS#7 certificate chain. This also enables to >> add new file hashes to be denied by the integrity infrastructure. >> >> Being able to untrust a certificate which could have normaly been >> trusted is a sensitive operation. This is why adding new hashes to the >> blacklist keyring is only allowed when these hashes are signed and >> vouched by the builtin trusted keyring. A blacklist hash is stored as a >> key description. The PKCS#7 signature of this description must be >> provided as the key payload. >> >> Marking a certificate as untrusted should be enforced while the system >> is running. It is then forbiden to remove such blacklist keys. >> >> Update blacklist keyring and blacklist key access rights: >> * allows the root user to search for a specific blacklisted hash, which >> make sense because the descriptions are already viewable; >> * forbids key update; >> * restricts kernel rights on the blacklist keyring to align with the >> root user rights. >> >> See the help in tools/certs/print-cert-tbs-hash.sh provided by a >> following commit. > > Please re-order patches in a way that print-cert-tbs-hash.sh is > available before this. That way we get rid of this useless remark. OK > >> Cc: David Howells <dhowells@redhat.com> >> Cc: David Woodhouse <dwmw2@infradead.org> >> Signed-off-by: Mickaël Salaün <mic@linux.microsoft.com> > > /Jarkko >
diff --git a/certs/Kconfig b/certs/Kconfig index c94e93d8bccf..35fe9989e7b9 100644 --- a/certs/Kconfig +++ b/certs/Kconfig @@ -83,4 +83,14 @@ config SYSTEM_BLACKLIST_HASH_LIST wrapper to incorporate the list into the kernel. Each <hash> should be a string of hex digits. +config SYSTEM_BLACKLIST_AUTH_UPDATE + bool "Allow root to add signed blacklist keys" + depends on SYSTEM_BLACKLIST_KEYRING + depends on SYSTEM_DATA_VERIFICATION + help + If set, provide the ability to load new blacklist keys at run time if + they are signed and vouched by a certificate from the builtin trusted + keyring. The PKCS#7 signature of the description is set in the key + payload. Blacklist keys cannot be removed. + endmenu diff --git a/certs/blacklist.c b/certs/blacklist.c index 1e63971bea94..07c592ae5307 100644 --- a/certs/blacklist.c +++ b/certs/blacklist.c @@ -15,6 +15,7 @@ #include <linux/err.h> #include <linux/seq_file.h> #include <linux/uidgid.h> +#include <linux/verification.h> #include <keys/system_keyring.h> #include "blacklist.h" @@ -25,6 +26,9 @@ */ #define MAX_HASH_LEN 128 +#define BLACKLIST_KEY_PERM (KEY_POS_SEARCH | KEY_POS_VIEW | \ + KEY_USR_SEARCH | KEY_USR_VIEW) + static const char tbs_prefix[] = "tbs"; static const char bin_prefix[] = "bin"; @@ -74,19 +78,51 @@ static int blacklist_vet_description(const char *desc) return 0; } -/* - * The hash to be blacklisted is expected to be in the description. There will - * be no payload. - */ -static int blacklist_preparse(struct key_preparsed_payload *prep) +static int blacklist_key_instantiate(struct key *key, + struct key_preparsed_payload *prep) { - if (prep->datalen > 0) - return -EINVAL; - return 0; +#ifdef CONFIG_SYSTEM_BLACKLIST_AUTH_UPDATE + int err; +#endif + + /* Sets safe default permissions for keys loaded by user space. */ + key->perm = BLACKLIST_KEY_PERM; + + /* + * Skips the authentication step for builtin hashes, they are not + * signed but still trusted. + */ + if (key->flags & (1 << KEY_FLAG_BUILTIN)) + goto out; + +#ifdef CONFIG_SYSTEM_BLACKLIST_AUTH_UPDATE + /* + * Verifies the description's PKCS#7 signature against the builtin + * trusted keyring. + */ + err = verify_pkcs7_signature(key->description, + strlen(key->description), prep->data, prep->datalen, + NULL, VERIFYING_UNSPECIFIED_SIGNATURE, NULL, NULL); + if (err) + return err; +#else + /* + * It should not be possible to come here because the keyring doesn't + * have KEY_USR_WRITE and the only other way to call this function is + * for builtin hashes. + */ + WARN_ON_ONCE(1); + return -EPERM; +#endif + +out: + return generic_key_instantiate(key, prep); } -static void blacklist_free_preparse(struct key_preparsed_payload *prep) +static int blacklist_key_update(struct key *key, + struct key_preparsed_payload *prep) { + return -EPERM; } static void blacklist_describe(const struct key *key, struct seq_file *m) @@ -97,9 +133,8 @@ static void blacklist_describe(const struct key *key, struct seq_file *m) static struct key_type key_type_blacklist = { .name = "blacklist", .vet_description = blacklist_vet_description, - .preparse = blacklist_preparse, - .free_preparse = blacklist_free_preparse, - .instantiate = generic_key_instantiate, + .instantiate = blacklist_key_instantiate, + .update = blacklist_key_update, .describe = blacklist_describe, }; @@ -148,8 +183,7 @@ static int mark_raw_hash_blacklisted(const char *hash) hash, NULL, 0, - ((KEY_POS_ALL & ~KEY_POS_SETATTR) | - KEY_USR_VIEW), + BLACKLIST_KEY_PERM, KEY_ALLOC_NOT_IN_QUOTA | KEY_ALLOC_BUILT_IN); if (IS_ERR(key)) { @@ -208,25 +242,43 @@ int is_binary_blacklisted(const u8 *hash, size_t hash_len) } EXPORT_SYMBOL_GPL(is_binary_blacklisted); +static int restrict_link_for_blacklist(struct key *dest_keyring, + const struct key_type *type, const union key_payload *payload, + struct key *restrict_key) +{ + if (type != &key_type_blacklist) + return -EPERM; + return 0; +} + /* * Initialise the blacklist */ static int __init blacklist_init(void) { const char *const *bl; + struct key_restriction *restriction; if (register_key_type(&key_type_blacklist) < 0) panic("Can't allocate system blacklist key type\n"); + restriction = kzalloc(sizeof(*restriction), GFP_KERNEL); + if (!restriction) + panic("Can't allocate blacklist keyring restriction\n"); + restriction->check = restrict_link_for_blacklist; + blacklist_keyring = keyring_alloc(".blacklist", GLOBAL_ROOT_UID, GLOBAL_ROOT_GID, current_cred(), - (KEY_POS_ALL & ~KEY_POS_SETATTR) | - KEY_USR_VIEW | KEY_USR_READ | - KEY_USR_SEARCH, - KEY_ALLOC_NOT_IN_QUOTA | + KEY_POS_VIEW | KEY_POS_READ | KEY_POS_SEARCH | + KEY_POS_WRITE | + KEY_USR_VIEW | KEY_USR_READ | KEY_USR_SEARCH +#ifdef CONFIG_SYSTEM_BLACKLIST_AUTH_UPDATE + | KEY_USR_WRITE +#endif + , KEY_ALLOC_NOT_IN_QUOTA | KEY_ALLOC_SET_KEEP, - NULL, NULL); + restriction, NULL); if (IS_ERR(blacklist_keyring)) panic("Can't allocate system blacklist keyring\n");