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

[Eric Snowberg <eric.snowberg@oracle.com>]

> On Sep 11, 2023, at 5:08 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> 
> On Mon, 2023-09-11 at 22:17 +0000, Eric Snowberg wrote:
>> 
>>> On Sep 11, 2023, at 10:51 AM, Mickaël Salaün <mic@digikod.net> 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@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? 
>> 
>>> 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.

But, if you think it would be appropriate, I could add a new Kconfig (disabled 
by default) that validates the key being used to vouch the S/MIME encoded 
hash is a CA.  That would certainly make this more complicated.   With this 
addition, would  the key usage field need to be referenced too?

Another idea I had was changing this patch to reference only the builtin and 
the machine keyring (if configured), not the secondary keyring.   Then with
INTEGRITY_CA_MACHINE_KEYRING_MAX, only CA keys could be 
used. Let me know your thoughts on this approach.  Thanks.