Linux 6.4 Allows For Optional CA Enforcement Of The Machine Keyring
With the Linux 6.4 kernel there is the ability being introduced so that the machine keyring can optionally only store CA-enforced keys.
Eric Snowberg of Oracle has been working on CA enforcement keyring restrictions so that there can be Certificate Authority (CA) enforcement of the machine keyring. Snowberg explained in the patch series:
Again, as stated, this is strictly opt-in with the default behavior allowing all MOK keys into the machine keyring.
The TPMDD pull request was sent out today for the Linux 6.4 kernel and includes this new functionality.
Linux enhancements around the Integrity Measurement Architecture (IMA) handling remain a big area of interest for corporate stakeholders.
Eric Snowberg of Oracle has been working on CA enforcement keyring restrictions so that there can be Certificate Authority (CA) enforcement of the machine keyring. Snowberg explained in the patch series:
"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 enforcement with the machine keyring. It introduces three different ways to configure the machine keyring. New Kconfig options are added to control the types of keys that may be added to it. The default option allows all MOK keys into the machine keyring. When CONFIG_INTEGRITY_CA_MACHINE_KEYRING is selected, the X.509 CA bit must be true and the key usage must contain keyCertSign; any other usage field may also be set. When
CONFIG_INTEGRITY_CA_MACHINE_KEYRING_MAX is also selected, the X.509 CA bit must be true and the key usage must contain keyCertSign. With this option 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."
Again, as stated, this is strictly opt-in with the default behavior allowing all MOK keys into the machine keyring.
The TPMDD pull request was sent out today for the Linux 6.4 kernel and includes this new functionality.
"The .machine keyring, used for Machine Owner Keys (MOK), acquired the ability to store only CA enforced keys, and put rest to the .platform keyring, thus separating the code signing keys from the keys that are used to sign certificates. This essentially unlocks the use of the .machine keyring as a trust anchor for IMA. It is an opt-in feature, meaning that the additional constraints won't brick anyone who does not care about them."
Linux enhancements around the Integrity Measurement Architecture (IMA) handling remain a big area of interest for corporate stakeholders.
4 Comments