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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <932231F5-8050-4436-84B8-D7708DC43845@oracle.com>
Date:   Tue, 12 Sep 2023 02:00:27 +0000
From:   Eric Snowberg <eric.snowberg@...cle.com>
To:     Mimi Zohar <zohar@...ux.ibm.com>
CC:     Mickaël Salaün <mic@...ikod.net>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        David Howells <dhowells@...hat.com>,
        David Woodhouse <dwmw2@...radead.org>,
        "mic@...ux.microsoft.com" <mic@...ux.microsoft.com>,
        Kanth Ghatraju <kanth.ghatraju@...cle.com>,
        Konrad Wilk <konrad.wilk@...cle.com>,
        "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        "keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>,
        Paul Moore <paul@...l-moore.com>
Subject: Re: [PATCH] certs: Restrict blacklist updates to the secondary
 trusted keyring



> On Sep 11, 2023, at 5:08 PM, Mimi Zohar <zohar@...ux.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@...ikod.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@...cle.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.