Message-ID: <1149b6dbfdaabef3e48dc2852cc76aa11a6dd6b0.camel@linux.ibm.com>
Date:   Tue, 12 Sep 2023 18:47:00 -0400
From:   Mimi Zohar <zohar@...ux.ibm.com>
To:     Eric Snowberg <eric.snowberg@...cle.com>,
        Jarkko Sakkinen <jarkko@...nel.org>
Cc:     Mickaël Salaün <mic@...ikod.net>,
        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 Tue, 2023-09-12 at 17:11 +0000, Eric Snowberg wrote:
> 
> > On Sep 12, 2023, at 5:54 AM, Mimi Zohar <zohar@...ux.ibm.com> wrote:
> > 
> > On Tue, 2023-09-12 at 02:00 +0000, Eric Snowberg wrote:
> >> 
> >>> 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.
> > 
> > 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/

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

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

Mimi

Powered by blists - more mailing lists