RFC: New LSM to control usage of x509 certificates

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

The initial subject was "Re: [PATCH] certs: Restrict blacklist updates
to the secondary trusted keyring":
https://lore.kernel.org/all/20230908213428.731513-1-eric.snowberg@oracle.com/

On Thu, Sep 14, 2023 at 10:34:44AM +0200, Mickaël Salaün wrote:
> 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.
> >