[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <A4CD568A-6D8E-4043-971B-8E79FFB58709@oracle.com>
Date: Mon, 15 Mar 2021 10:59:16 -0600
From: Eric Snowberg <eric.snowberg@...cle.com>
To: Mickaël Salaün <mic@...ikod.net>
Cc: David Howells <dhowells@...hat.com>,
David Woodhouse <dwmw2@...radead.org>,
Jarkko Sakkinen <jarkko@...nel.org>,
"David S . Miller" <davem@...emloft.net>,
Herbert Xu <herbert@...dor.apana.org.au>,
James Morris <jmorris@...ei.org>,
Mickaël Salaün <mic@...ux.microsoft.com>,
Mimi Zohar <zohar@...ux.ibm.com>,
"Serge E . Hallyn" <serge@...lyn.com>,
Tyler Hicks <tyhicks@...ux.microsoft.com>,
keyrings@...r.kernel.org, linux-crypto@...r.kernel.org,
linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org
Subject: Re: [PATCH v7 5/5] certs: Allow root user to append signed hashes to
the blacklist keyring
> On Mar 12, 2021, at 10:12 AM, Mickaël Salaün <mic@...ikod.net> wrote:
>
> From: Mickaël Salaün <mic@...ux.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@...hat.com>
> Cc: David Woodhouse <dwmw2@...radead.org>
> Cc: Eric Snowberg <eric.snowberg@...cle.com>
> Cc: Jarkko Sakkinen <jarkko@...nel.org>
> Signed-off-by: Mickaël Salaün <mic@...ux.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?
Powered by blists - more mailing lists