Linux-Security-Module Archive on
 help / color / Atom feed
From: Eric Snowberg <>
To: "Mickaël Salaün" <>
Cc: "David Howells" <>,
	"David Woodhouse" <>,
	"Jarkko Sakkinen" <>,
	"David S . Miller" <>,
	"Herbert Xu" <>,
	"James Morris" <>,
	"Mickaël Salaün" <>,
	"Mimi Zohar" <>,
	"Serge E . Hallyn" <>,
	"Tyler Hicks" <>,,,
	linux-integrity <>,,
Subject: Re: [PATCH v7 5/5] certs: Allow root user to append signed hashes to the blacklist keyring
Date: Wed, 17 Mar 2021 08:48:11 -0600
Message-ID: <> (raw)
In-Reply-To: <>

> On Mar 15, 2021, at 12:01 PM, Mickaël Salaün <> wrote:
> On 15/03/2021 17:59, Eric Snowberg wrote:
>>> On Mar 12, 2021, at 10:12 AM, Mickaël Salaün <> wrote:
>>> From: Mickaël Salaün <>
>>> 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/ .
>>> Cc: David Howells <>
>>> Cc: David Woodhouse <>
>>> Cc: Eric Snowberg <>
>>> Cc: Jarkko Sakkinen <>
>>> Signed-off-by: Mickaël Salaün <>
>>> Link:
>> 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?

  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 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
2021-03-17 14:48       ` Eric Snowberg [this message]
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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

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

Linux-Security-Module Archive on

Archives are clonable:
	git clone --mirror 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/ \
	public-inbox-index linux-security-module

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone