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. thanks, Mimi
