> 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. I’m assuming this would be follow on work?
