From: Eric Snowberg <eric.snowberg@oracle.com>
To: "Mickaël Salaün" <mic@digikod.net>
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 <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: Wed, 17 Mar 2021 08:48:11 -0600 [thread overview]
Message-ID: <5111D396-9910-48E9-8D91-6433E719EDB5@oracle.com> (raw)
In-Reply-To: <bd28dd0b-b183-44bd-1928-59e3e1274045@digikod.net>
> On Mar 15, 2021, at 12:01 PM, Mickaël Salaün <mic@digikod.net> wrote:
>
>
> 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.
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?
next prev parent reply other threads:[~2021-03-17 14:49 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-12 17:12 [PATCH v7 0/5] Enable root to update the blacklist keyring 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
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
2022-04-20 10:29 ` [PATCH v7 3/5] certs: Make blacklist_vet_description() more strict David Howells
2022-04-21 15:12 ` Jarkko Sakkinen
2022-04-21 15:27 ` Mickaël Salaün
2022-04-21 15:57 ` Jarkko Sakkinen
2022-04-21 17:29 ` Mickaël Salaün
2022-04-22 8:54 ` Jarkko Sakkinen
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=5111D396-9910-48E9-8D91-6433E719EDB5@oracle.com \
--to=eric.snowberg@oracle.com \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=dwmw2@infradead.org \
--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@digikod.net \
--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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).