linux-kernel - Re: [PATCH v7 5/5] certs: Allow root user to append signed hashes to the blacklist keyring

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <5111D396-9910-48E9-8D91-6433E719EDB5@oracle.com>
Date:   Wed, 17 Mar 2021 08:48:11 -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 <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 15, 2021, at 12:01 PM, Mickaël Salaün <mic@...ikod.net> wrote:
> 
> 
> On 15/03/2021 17:59, Eric Snowberg wrote:
>> 
>>> 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?
> 
> 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.

Is there a non technical reason why this can not be changed to also apply to
builtin trusted keys? If a user had the same tbs cert hash in their dbx and 
soon mokx, the hash would show up in the .blacklist keyring and invalidate 
any key in the builtin_trusted_keys keyring. After adding the same hash with 
this series, it shows up in the .blacklist_keyring but the value is ignored 
by operations using the builtin_trusted_keys keyring.  It just seems 
incomplete to me, or did I miss an earlier discussion on this topic?