> On Dec 15, 2022, at 2:03 PM, Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: > > On Thu, 2022-12-15 at 20:28 +0000, Eric Snowberg wrote: >> >>> On Dec 15, 2022, at 12:58 PM, Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: >>> >>> On Thu, 2022-12-15 at 16:26 +0000, Eric Snowberg wrote: >>>> >>>>> On Dec 15, 2022, at 3:21 AM, Mimi Zohar <zohar@xxxxxxxxxxxxx> wrote: >>>>> >>>>> On Tue, 2022-12-13 at 19:33 -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. Any key in the builtin or secondary keyring can be used. >>>>>> >>>>>> To allow IMA to be enabled with the machine keyring, this series introduces >>>>>> enforcement of key usage in the certificate. This series also applies >>>>>> this enforcement across all kernel keyrings. >>>>>> >>>>>> The machine keyring shares similarities with both the builtin and >>>>>> secondary keyrings. Similar to the builtin, no keys may be added to the >>>>>> machine keyring following boot. The secondary keyring allows user >>>>>> provided keys to be added following boot; however, a previously enrolled >>>>>> kernel key must vouch for the key before it may be included. The system >>>>>> owner may include their own keys into the machine keyring prior to boot. >>>>>> If the end-user is not the system owner, they may not add their own keys >>>>>> to the machine keyring. >>>>>> >>>>>> The machine keyring is only populated when Secure Boot is enabled. A >>>>>> system owner has the ability to control the entire Secure Boot keychain >>>>>> (PK, KEK, DB, and DBX). The system owner can also turn Secure Boot off. >>>>>> With this control, they may use insert-sys-cert to include their own key >>>>>> and re-sign their kernel and have it boot. The system owner also has >>>>>> control to include or exclude MOK keys. This series does not try to >>>>>> interpret how a system owner has configured their machine. If the system >>>>>> owner has taken the steps to add their own MOK keys, they will be >>>>>> included in the machine keyring and used for verification, exactly >>>>>> the same way as keys contained in the builtin and secondary keyrings. >>>>>> Since the system owner has the ability to add keys before booting to >>>>>> either the machine or builtin keyrings, it is viewed as inconsequential >>>>>> if the key originated from one or the other. >>>>>> >>>>>> This series introduces two different ways to configure the machine keyring. >>>>>> By default, nothing changes and all MOK keys are loaded into it. Whenever >>>>>> a CA cert is found within the machine, builtin, or secondary, a flag >>>>>> indicating this is stored in the public key struct. The other option is >>>>>> if the new Kconfig INTEGRITY_CA_MACHINE_KEYRING is enabled, only CA certs >>>>>> will be loaded into the machine keyring. All remaining MOK keys will be >>>>>> loaded into the platform keyring. >>>>>> >>>>>> A CA cert shall be defined as any X509 certificate that contains the >>>>>> keyCertSign key usage and has the CA bit set to true. >>>>> >>>>> Hi Eric, >>>>> >>>>> Allowing CA certificates with the digitalSignature key usage flag >>>>> enabled defeats the purpose of the new Kconfig. Please update the >>>>> above definition to exclude the digitalSignature key usage flag and >>>>> modify the code accordingly. >>>> >>>> Within v2, the request was made to allow Intermediate CA certificates to be >>>> loaded directly. The Intermediate CA referenced was the one used by kernel.org. >>>> This Intermediate CA contains both digitalSignature and keyCertSign. If the code >>>> is changed to exclude this certificate, now the root CA has to be loaded again. Is that >>>> the intent? >>> >>> That definitely was not the intent. Nor would it address the issue of >>> a particular intermediate CA certificate having both keyCertSign and >>> digitalSignature. >> >> Sorry, I’m not following. Why is it an issue that an intermediate CA certificate contains >> both keyCertSign and digitalSignature? Why would we want to exclude an Intermediate >> CA cert like the one used on kernel.org? > > I must be missing something. Isn't the purpose of "keyUsage" to > minimize how a certificate may be used? Why would we want the same > certificate to be used for both certificate signing and code signing? Every 3rd party intermediate CA I have looked at so far contains both set. Most have CRLSign set. Typically the root CA contains keyCertSign and CRLSign, but some also have digitalSignature set. Finding a 3rd party Intermediate CA without digitalSignature set is probably going to be challenging and will severely limit usage.
