Messages in this thread | | | Subject | Re: [PATCH v7 5/5] certs: Allow root user to append signed hashes to the blacklist keyring | From | Mickaël Salaün <> | Date | Mon, 15 Mar 2021 19:01:36 +0100 |
| |
On 15/03/2021 17:59, Eric Snowberg wrote: > >> On Mar 12, 2021, at 10:12 AM, Mickaël Salaün <mic@digikod.net> 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, blacklist key and revoked certificate 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 (blacklist and asymmetric ones); >> * restricts kernel rights on the blacklist keyring to align with the >> root user rights. >> >> See help in tools/certs/print-cert-tbs-hash.sh . >> >> Cc: David Howells <dhowells@redhat.com> >> Cc: David Woodhouse <dwmw2@infradead.org> >> Cc: Eric Snowberg <eric.snowberg@oracle.com> >> Cc: Jarkko Sakkinen <jarkko@kernel.org> >> Signed-off-by: Mickaël Salaün <mic@linux.microsoft.com> >> Link: https://lore.kernel.org/r/20210312171232.2681989-6-mic@digikod.net > > I tried testing this, it doesn’t work as I would expect. > Here is my test setup: > > Kernel built with two keys compiled into the builtin_trusted_keys keyring > > Generated a tbs cert from one of the keys and signed it with the other key > > As root, added the tbs cert hash to the blacklist keyring > > Verified the tbs hash is in the blacklist keyring > > Enabled lockdown to enforce kernel module signature checking > > Signed a kernel module with the key I just blacklisted > > Load the kernel module > > I’m seeing the kernel module load, I would expect this to fail, since the > key is now blacklisted. Or is this change just supposed to prevent new keys > from being added in the future?
This is the expected behavior and the way the blacklist keyring is currently used, as explained in the commit message: "This enables to invalidate new certificates, either from being loaded in a keyring, or from being trusted in a PKCS#7 certificate chain."
If you want a (trusted root) key to be untrusted, you need to remove it from the keyring, which is not allowed for the builtin trusted keyring.
| |