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

[Eric Snowberg]

> On Sep 11, 2023, at 10:51 AM, Mickaël Salaün <mic@xxxxxxxxxxx> wrote:
> 
> On Mon, Sep 11, 2023 at 09:29:07AM -0400, Mimi Zohar wrote:
>> Hi Eric,
>> 
>> On Fri, 2023-09-08 at 17:34 -0400, Eric Snowberg wrote:
>>> 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@xxxxxxxxxx>
>> 
>> 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? 

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

I suppose root could add another key to the secondary keyring if it was 
signed by a key in the machine keyring.  But then we are getting into an 
area of key usage enforcement which really only exists for things added 
to the .ima keyring. 

>>> ---
>>> certs/Kconfig     | 2 +-
>>> certs/blacklist.c | 4 ++--
>>> 2 files changed, 3 insertions(+), 3 deletions(-)
>>> 
>>> diff --git a/certs/Kconfig b/certs/Kconfig
>>> index 1f109b070877..23dc87c52aff 100644
>>> --- a/certs/Kconfig
>>> +++ b/certs/Kconfig
>>> @@ -134,7 +134,7 @@ config SYSTEM_BLACKLIST_AUTH_UPDATE
>>> 	depends on SYSTEM_DATA_VERIFICATION
>>> 	help
>>> 	  If set, provide the ability to load new blacklist keys at run time if
>>> -	  they are signed and vouched by a certificate from the builtin trusted
>>> +	  they are signed and vouched by a certificate from the secondary trusted
>> 
>> If CONFIG_SECONDARY_TRUSTED_KEYRING is not enabled, it falls back to
>> the builtin keyring.  Please update the comment accordingly.

I’ll fix these in the next round, thanks.