Re: [PATCH v4 0/6] Add CA enforcement keyring restrictions

[Mimi Zohar <zohar@linux.ibm.com>]

On Wed, 2023-02-08 at 23:26 +0000, Eric Snowberg wrote:
> 
> > On Feb 8, 2023, at 5:38 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> > 
> > [CC'ing: Lee, Chun-Yi]
> > 
> > On Mon, 2023-02-06 at 21:59 -0500, Eric Snowberg wrote:
> >> Prior to the introduction of the machine keyring, most distros simply 
> >> allowed all keys contained within the platform keyring to be used
> >> for both kernel and module verification.  This was done by an out of
> >> tree patch.  Some distros took it even further and loaded all these keys
> >> into the secondary trusted keyring.  This also allowed the system owner 
> >> to add their own key for IMA usage.
> >> 
> >> Each distro contains similar documentation on how to sign kernel modules
> >> and enroll the key into the MOK.  The process is fairly straightforward.
> >> With the introduction of the machine keyring, the process remains
> >> basically the same, without the need for any out of tree patches.
> >> 
> >> The machine keyring allowed distros to eliminate the out of tree patches
> >> for kernel module signing.  However, it falls short in allowing the end 
> >> user to add their own keys for IMA. Currently, 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.  This would expand the current 
> >> integrity gap. The IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY 
> >> Kconfig states that keys may be added to the ima keyrings if the key is 
> >> validly signed by a CA cert in the system built-in or secondary trusted 
> >> keyring.  Currently, there is not code that enforces the contents of a
> >> CA cert.
> >> 
> >> This series introduces a way to do CA enforement with the machine
> >> keyring. It introduces three different ways to configure the machine
> >> keyring. A new menu option is added to control the type of keys that may
> >> be added to it.  The options include none, min, and max restrictions. The
> >> default is CONFIG_INTEGRITY_CA_MACHINE_KEYRING_NONE. This allows all MOK
> >> keys into the machine keyring.  When CONFIG_INTEGRITY_CA_MACHINE_KEYRING_MIN
> >> is selected, the X.509 CA bit must be true.  Also, the key usage must
> >> contain keyCertSign, any other usage field may also be set. When 
> >> CONFIG_INTEGRITY_CA_MACHINE_KEYRING_MAX is selected, the X.509 CA bit
> >> must be true.  Also, the key usage must contain keyCertSign and the
> >> digitialSignature usage may not be set. If a key doesn't pass the CA
> >> restriction check, instead of going into the machine keyring, it is
> >> added to the platform keyring. With the ability to configure the machine
> >> keyring with CA restrictions, code that prevented the machine keyring
> >> from being enabled with IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY
> >> has been removed.
> >> 
> >> Changelog:
> >> v4:
> >> - Removed all code that validated the certificate chain back to the root
> >>  CA. Now the only restriction is what is initially placed in the
> >>  machine keyring.
> >> - Check and store if the X.509 usage contains digitalSignature
> >> - New Kconfig menu item with none, min and max CA restriction on the 
> >>  machine keyring
> > 
> > Thank you, Eric.
> > 
> > For complete separation of certificate usage, at least in the "max" CA
> > restriction case, the next step would be to limit certificates being
> > loaded onto the IMA keyring to those with key usage of
> > "digitalSignature".
> > 
> > Perhaps also require a "codeSigning" extendedKeyUsage, though that
> > might break existing usages.  The "codeSigning" checking could
> > piggyback on Joey's proposed "Check codeSigning extended key usage
> > extension" patch set.
> > 
> > What do you think?  Do you have any concerns with limiting the type of
> > certificate being loaded onto the IMA keyring to those with
> > "digitalSignature"?
> 
> In the MAX setting I would not have a concern.  Instead of restrict_link_to_ima 
> being a macro, a new restriction similar to restrict_link_by_ca could be created.  
> The new restriction would simply verify digitialSignature is set and the key can be 
> vouched for by either the built-in or secondary keyrings. Joey’s work to parse 
> the extended key usage extension could also be included in this restriction.

Sounds good.

> I’m assuming this would be follow on work?

Yes, that probably makes the most sense.

-- 
thanks,

Mimi