Re: [PATCH] certs: Restrict blacklist updates to the secondary trusted keyring

CCing the LSM mailing list for this potential new LSM proposal:

On Wed, Sep 13, 2023 at 10:29:58PM +0000, Eric Snowberg wrote:

quoted

On Sep 13, 2023, at 4:21 AM, Mickaël Salaün [off-list ref] wrote:

On Wed, Sep 13, 2023 at 02:40:17AM +0000, Eric Snowberg wrote:

quoted

quoted

On Sep 12, 2023, at 4:47 PM, Mimi Zohar [off-list ref] wrote:

On Tue, 2023-09-12 at 17:11 +0000, Eric Snowberg wrote:

quoted

quoted

On Sep 12, 2023, at 5:54 AM, Mimi Zohar [off-list ref] wrote:

On Tue, 2023-09-12 at 02:00 +0000, Eric Snowberg wrote:

quoted

quoted

On Sep 11, 2023, at 5:08 PM, Mimi Zohar [off-list ref] wrote:

On Mon, 2023-09-11 at 22:17 +0000, Eric Snowberg wrote:

quoted

quoted

On Sep 11, 2023, at 10:51 AM, Mickaël Salaün [off-list ref] wrote:

On Mon, Sep 11, 2023 at 09:29:07AM -0400, Mimi Zohar wrote:

quoted

Hi Eric,

On Fri, 2023-09-08 at 17:34 -0400, Eric Snowberg wrote:

quoted

Currently root can dynamically update the blacklist keyring if the hash
being added is signed and vouched for by the builtin trusted keyring.
Currently keys in the secondary trusted keyring can not be used.

Keys within the secondary trusted keyring carry the same capabilities as
the builtin trusted keyring.  Relax the current restriction for updating
the .blacklist keyring and allow the secondary to also be referenced as
a trust source.  Since the machine keyring is linked to the secondary
trusted keyring, any key within it may also be used.

An example use case for this is IMA appraisal.  Now that IMA both
references the blacklist keyring and allows the machine owner to add
custom IMA CA certs via the machine keyring, this adds the additional
capability for the machine owner to also do revocations on a running
system.

IMA appraisal usage example to add a revocation for /usr/foo:

sha256sum /bin/foo | awk '{printf "bin:" $1}' > hash.txt

openssl smime -sign -in hash.txt -inkey machine-private-key.pem \
  -signer machine-certificate.pem -noattr -binary -outform DER \
  -out hash.p7s

keyctl padd blacklist "$(< hash.txt)" %:.blacklist < hash.p7s

Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>

The secondary keyring may include both CA and code signing keys.  With
this change any key loaded onto the secondary keyring may blacklist a
hash.  Wouldn't it make more sense to limit blacklisting
certificates/hashes to at least CA keys? 

Some operational constraints may limit what a CA can sign.

Agreed.  

Is there precedents for requiring this S/MIME to be signed by a CA? 

quoted

This change is critical and should be tied to a dedicated kernel config
(disabled by default), otherwise existing systems using this feature
will have their threat model automatically changed without notice.

Today we have INTEGRITY_CA_MACHINE_KEYRING_MAX.  This can 
be enabled to enforce CA restrictions on the machine keyring.  Mimi, would 
this be a suitable solution for what you are after?

There needs to be some correlation between the file hashes being added
to the blacklist and the certificate that signed them.  Without that
correlation, any key on the secondary trusted keyring could add any
file hashes it wants to the blacklist.

Today any key in the secondary trusted keyring can be used to validate a 
signed kernel module.  At a later time, if a new hash is added to the blacklist 
keyring to revoke loading a signed kernel module,  the ability to do the 
revocation with this additional change would be more restrictive than loading 
the original module.

A public key on the secondary keyring is used to verify code that it
signed, but does not impact any other code. Allowing any public key on
the secondary keyring to blacklist any file hash is giving it more
privileges than it originally had.

This requirement isn't different than how Certificate Revocation List
(CRL) work.  Not any CA can revoke a certificate.

In UEFI Secure Boot we have the Forbidden Signature Database (DBX).  
Root can update the DBX on a host.  The requirement placed on updating 
it is the new DBX entry must be signed by any key contained within the 
KEK.  Following a reboot, all DBX entries load into the .blacklist keyring.  
There is not a requirement similar to how CRL’s work here, any KEK key 
can be used.

With architectures booted through a shim there is the MOKX.  Similar to 
DBX, MOKX have the same capabilities, however they do not need to be 
signed by any key, the machine owner must show they have physical 
presence (and potentially a MOK password) for inclusion.  Again there 
is not a requirement similar to how CRL’s work here either.  The machine 
owner can decide what is included.

Today when a kernel is built, any number of keys may be included within 
the builtin trusted keyring.  The keys included in the kernel may not have 
a single usage field set or the CA bit set.  There are no requirements on 
how these keys get used later on.  Any key in the builtin trusted keyring 
can be used to sign a revocation that can be added to the blacklist keyring.  
Additionally, any key in the MOK can be used to sign this kernel and it will 
boot.  Before booting the kernel, MOK keys have more privileges than 
after the kernel is booted in some instances.

Today MOK keys can be loaded into the machine keyring.  These keys get 
linked to the secondary trusted keyring.  Currently key usage enforcement
is being applied to these keys behind some Kconfig options.  By default 
anything in the secondary has the same capabilities as the builtin trusted 
keyring.  What is challenging here with this request is the inconsistency 
between how everything else currently works. 

Root can not arbitrarily add things to the secondary trusted keyring.  These 
keys must be signed by something in either the machine or the builtin.  In 
this thread [1], Jarkko is saying CA based infrastructure should be a policy 
decision not to be enforced by the kernel. Wouldn’t this apply here as well?

1. https://lore.kernel.org/lkml/CVGUFUEQVCHS.37OA20PNG9EVB@suppilovahvero/ (local)

Mickaël said, "This change is critical and should be tied to a
dedicated kernel config
(disabled by default), otherwise existing systems using this feature
will have their threat model automatically changed without notice."

I was thinking he meant it is critical not to change the current behavior
by limiting blacklisting to only CA keys.  Not that it was critical to add
CA enforcement.  Maybe Mickaël can comment?

I meant that applying this patch as-is may change the threat model used
by some users. Currently, only signed hashes vouched by the builtin
trusted keyring are valid. If we extend this mechanism to the secondary
trusted keyring without notice, this means that more certificates could
vouch blacklisted hashes, which may include some certificates with an
initial different usage.

See commit 4da8f8c8a1e0 ("dm verity: Add support for signature
verification with 2nd keyring") that adds
CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING:
https://lore.kernel.org/all/20201023170512.201124-1-mic@digikod.net/ (local)

Thanks for clarifying.  I’ll add something similar in v2.

quoted

quoted

quoted

As a possible alternative I suggested limiting which file hashes the
certs on the secondary (or machine) keyring could blacklist.

I’m not sure I completely understand your suggestion here.
Do you mean, verify the CA bit is set for secondary keys, but
ignore the bit for builtin?  And then only use those keys to add
hashes to the blacklist keyring?  If I have that right, what would 
be the justification for the change based on how things currently
get included in the blacklist keyring?  Thanks.

I'd like to be able to specify which kind of certificate can vouch for
blacklisting hashes, and for other usages, but AFAIK this is not the
path Linux has followed (e.g. unlike Windows). We only have the keyring
to identify an usage, which is unfortunate. On the other side, this
approach lets users manage their certificates without constraint, which
is quite (too?) flexible.

Yes, it is very flexible. What I believe Mimi is after is having a way to 
track what cert actually vouched for each specific binary hash.  But this
information is not tracked, plus entries within it can come from various 
sources that are not signed (dbx, mokx, compiled in).  Also key usage is 
being ignored.

quoted

A complementary approach would be to create an
LSM (or a dedicated interface) to tie certificate properties to a set of
kernel usages, while still letting users configure these constraints.

That is an interesting idea.  Would the other security maintainers be in 
support of such an approach?  Would a LSM be the correct interface?  
Some of the recent work I have done with introducing key usage and CA 
enforcement is difficult for a distro to pick up, since these changes can be 
viewed as a regression.  Each end-user has different signing procedures 
and policies, so making something work for everyone is difficult.  Letting the 
user configure these constraints would solve this problem.