Linux-Security-Module Archive on lore.kernel.org
 help / color / Atom feed
From: "Mickaël Salaün" <mic@digikod.net>
To: Eric Snowberg <eric.snowberg@oracle.com>
Cc: "David Howells" <dhowells@redhat.com>,
	"David Woodhouse" <dwmw2@infradead.org>,
	"Jarkko Sakkinen" <jarkko@kernel.org>,
	"David S . Miller" <davem@davemloft.net>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	"James Morris" <jmorris@namei.org>,
	"Mickaël Salaün" <mic@linux.microsoft.com>,
	"Mimi Zohar" <zohar@linux.ibm.com>,
	"Serge E . Hallyn" <serge@hallyn.com>,
	"Tyler Hicks" <tyhicks@linux.microsoft.com>,
	keyrings@vger.kernel.org, linux-crypto@vger.kernel.org,
	linux-integrity@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org
Subject: Re: [PATCH v7 5/5] certs: Allow root user to append signed hashes to the blacklist keyring
Date: Mon, 15 Mar 2021 19:01:36 +0100
Message-ID: <bd28dd0b-b183-44bd-1928-59e3e1274045@digikod.net> (raw)
In-Reply-To: <A4CD568A-6D8E-4043-971B-8E79FFB58709@oracle.com>


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.

  reply index

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-12 17:12 [PATCH v7 0/5] Enable root to update " Mickaël Salaün
2021-03-12 17:12 ` [PATCH v7 1/5] tools/certs: Add print-cert-tbs-hash.sh Mickaël Salaün
2021-03-15 16:57   ` Eric Snowberg
2021-03-12 17:12 ` [PATCH v7 2/5] certs: Check that builtin blacklist hashes are valid Mickaël Salaün
2021-03-13 18:53   ` Jarkko Sakkinen
2021-03-12 17:12 ` [PATCH v7 3/5] certs: Make blacklist_vet_description() more strict Mickaël Salaün
2021-03-12 17:12 ` [PATCH v7 4/5] certs: Factor out the blacklist hash creation Mickaël Salaün
2021-03-13 18:54   ` Jarkko Sakkinen
2021-03-12 17:12 ` [PATCH v7 5/5] certs: Allow root user to append signed hashes to the blacklist keyring Mickaël Salaün
2021-03-15 16:59   ` Eric Snowberg
2021-03-15 18:01     ` Mickaël Salaün [this message]
2021-03-17 14:48       ` Eric Snowberg
2021-03-17 15:45         ` Mickaël Salaün
2021-03-25 11:36 ` [PATCH v7 0/5] Enable root to update " Mickaël Salaün
2021-04-07 17:21 ` Mickaël Salaün
2021-05-04 10:31   ` Mickaël Salaün

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bd28dd0b-b183-44bd-1928-59e3e1274045@digikod.net \
    --to=mic@digikod.net \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=eric.snowberg@oracle.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=jarkko@kernel.org \
    --cc=jmorris@namei.org \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mic@linux.microsoft.com \
    --cc=serge@hallyn.com \
    --cc=tyhicks@linux.microsoft.com \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Security-Module Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-security-module/0 linux-security-module/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-security-module linux-security-module/ https://lore.kernel.org/linux-security-module \
		linux-security-module@vger.kernel.org
	public-inbox-index linux-security-module

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-security-module


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git