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: <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

Powered by Openwall GNU/*/Linux Powered by OpenVZ