On Wed, 2023-02-08 at 23:26 +0000, Eric Snowberg wrote: > > > On Feb 8, 2023, at 5:38 AM, Mimi Zohar <zohar@xxxxxxxxxxxxx> 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
