lkml.org 
[lkml]   [2022]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 0/7] Add CA enforcement keyring restrictions
From
Date
On Wed, 2022-04-06 at 22:53 +0000, Eric Snowberg wrote:
>
> > On Apr 6, 2022, at 2:45 PM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> >
> > Hi Eric,
> >
> > On Tue, 2022-04-05 at 21:53 -0400, Eric Snowberg wrote:
> >> A key added to the ima keyring must be signed by a key contained within
> >> either the builtin trusted or secondary trusted keyrings. Currently, there are
> >> CA restrictions described in IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY,
> >> but these restrictions are not enforced within code. Therefore, keys within
> >> either the builtin or secondary may not be a CA and could be used to
> >> vouch for an ima key.
> >>
> >> The machine keyring can not be used as another trust anchor for adding keys
> >> to the ima keyring, since CA enforcement does not currently exist [1]. This
> >> would expand the current integrity gap.
> >>
> >> Introduce a new root of trust key flag to close this integrity gap for
> >> all keyrings. The first key type to use this is X.509. When a X.509
> >> certificate is self signed, contains kernCertSign Key Usage and contains
> >> the CA bit, the new flag is set. Introduce new keyring restrictions
> >> that not only validates a key is signed by a key contained within the
> >> keyring, but also validates the key has the new root of trust key flag
> >> set. Use this new restriction for keys added to the ima keyring. Now
> >> that we have CA enforcement, allow the machine keyring to be used as another
> >> trust anchor for the ima keyring.
> >>
> >> To recap, all keys that previously loaded into the builtin, secondary or
> >> machine keyring will still load after applying this series. Keys
> >> contained within these keyrings may carry the root of trust flag. The
> >> ima keyring will use the new root of trust restriction to validate
> >> CA enforcement. Other keyrings that require a root of trust could also
> >> use this in the future.
> >
> > Your initial patch set indicated that you were addressing Linus'
> > request to allow end-users the ability "to add their own keys and sign
> > modules they trust". However, from the design of the previous patch
> > set and now this one, everything indicates a lot more is going on than
> > just allowing end-users to add their own keys. There would be no
> > reason for loading all the MOK keys, rather than just the CA keys, onto
> > the "machine" keyring. Please provide the motivation for this design.
>
> The motivation is to satisfy both Linus and your requests. Linus requested
> the ability to allow users to add their own keys and sign modules they trust.
> A code signing CA certificate does not require kernCertSign in the usage. Adding
> this as a requirement for kernel modules would be a regression (or a bug).

Of course a code signing CA certificate should not also be a
certificate signing key (keyCertSign). Remember the
"builtin_trusted_keys" and "secondary_trusted_keys" keyrings are
special. Their root of trust is based on a secure boot signature chain
of trust up to and including a signed kernel image. The "machine"
keyring is totally different in this regard. Establishing a new root
of trust is really difficult. Requiring a root-CA to have key
certifcate signing usage is a level of indirection, which I would
consider a small price to pay for being able to establish a, hopefully
safe or at least safer, new root of trust for trusting "end-user" keys.

>
> This series addresses your request to only trust validly signed CA certs.
> As you pointed out in the Kconfig help for
> IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY:
>
> help
> Keys may be added to the IMA or IMA blacklist keyrings, if the
> key is validly signed by a CA cert in the system built-in or
> secondary trusted keyrings.
>
> Intermediate keys between those the kernel has compiled in and the
> IMA keys to be added may be added to the system secondary keyring,
> provided they are validly signed by a key already resident in the
> built-in or secondary trusted keyrings.
>
> requires keys to be “validly” signed by a CA cert. Later the definition of a
> validly signed CA cert was defined as: self signed, contains kernCertSign
> key usage and contains the CA bit. While this help file states the CA restriction,
> nothing in code enforces it. One can place any type of self signed cert in either
> keyring and ima will use it. The motivation is for all keys added to the ima
> keyring to abide by the restriction defined in the Kconfig help. With this series
> this can be accomplished without introducing a regression on keys placed in
> any of the system keyrings.
>
> > Please note that Patch 6/7 permits intermediary CA keys, without any
> > mention of it in the cover letter. Please include this in the
> > motivation for this design.
>
> Ok, I’ll add that in the next round.

Your cover letter should say that this patch series enables
verification of 3rd party modules.

thanks,

Mimi

\
 
 \ /
  Last update: 2022-04-08 16:43    [W:0.943 / U:0.720 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site