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