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

["Mickaël Salaün" <mic@digikod.net>]

CCing the LSM mailing list for this potential new LSM proposal:

On Wed, Sep 13, 2023 at 10:29:58PM +0000, Eric Snowberg wrote:
> 
> 
> > On Sep 13, 2023, at 4:21 AM, Mickaël Salaün <mic@digikod.net> wrote:
> > 
> > On Wed, Sep 13, 2023 at 02:40:17AM +0000, Eric Snowberg wrote:
> >> 
> >> 
> >>> On Sep 12, 2023, at 4:47 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> >>> 
> >>> On Tue, 2023-09-12 at 17:11 +0000, Eric Snowberg wrote:
> >>>> 
> >>>>> On Sep 12, 2023, at 5:54 AM, Mimi Zohar <zohar@linux.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@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.
> >>>>> 
> >>>>> 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."
> >> 
> >> I was thinking he meant it is critical not to change the current behavior
> >> by limiting blacklisting to only CA keys.  Not that it was critical to add
> >> CA enforcement.  Maybe Mickaël can comment?
> > 
> > I meant that applying this patch as-is may change the threat model used
> > by some users. Currently, only signed hashes vouched by the builtin
> > trusted keyring are valid. If we extend this mechanism to the secondary
> > trusted keyring without notice, this means that more certificates could
> > vouch blacklisted hashes, which may include some certificates with an
> > initial different usage.
> > 
> > See commit 4da8f8c8a1e0 ("dm verity: Add support for signature
> > verification with 2nd keyring") that adds
> > CONFIG_DM_VERITY_VERIFY_ROOTHASH_SIG_SECONDARY_KEYRING:
> > https://lore.kernel.org/all/20201023170512.201124-1-mic@digikod.net/
> 
> Thanks for clarifying.  I’ll add something similar in v2.
> 
> >> 
> >>> As a possible alternative I suggested limiting which file hashes the
> >>> certs on the secondary (or machine) keyring could blacklist.
> >> 
> >> I’m not sure I completely understand your suggestion here.
> >> Do you mean, verify the CA bit is set for secondary keys, but
> >> ignore the bit for builtin?  And then only use those keys to add
> >> hashes to the blacklist keyring?  If I have that right, what would 
> >> be the justification for the change based on how things currently
> >> get included in the blacklist keyring?  Thanks.
> > 
> > I'd like to be able to specify which kind of certificate can vouch for
> > blacklisting hashes, and for other usages, but AFAIK this is not the
> > path Linux has followed (e.g. unlike Windows). We only have the keyring
> > to identify an usage, which is unfortunate. On the other side, this
> > approach lets users manage their certificates without constraint, which
> > is quite (too?) flexible.
> 
> Yes, it is very flexible. What I believe Mimi is after is having a way to 
> track what cert actually vouched for each specific binary hash.  But this
> information is not tracked, plus entries within it can come from various 
> sources that are not signed (dbx, mokx, compiled in).  Also key usage is 
> being ignored.
> 
> > A complementary approach would be to create an
> > LSM (or a dedicated interface) to tie certificate properties to a set of
> > kernel usages, while still letting users configure these constraints.
> 
> That is an interesting idea.  Would the other security maintainers be in 
> support of such an approach?  Would a LSM be the correct interface?  
> Some of the recent work I have done with introducing key usage and CA 
> enforcement is difficult for a distro to pick up, since these changes can be 
> viewed as a regression.  Each end-user has different signing procedures 
> and policies, so making something work for everyone is difficult.  Letting the 
> user configure these constraints would solve this problem.
>