At LSS 2022 NA, a recent talk titled, "Establishing Trust in Linux Keyrings – Is trust built-in, imputed, or transitive?"[1] triggered some discussion, which is best continued here. Background and current state as of Linux 5.18 --------------------------------------------- To save space, some terms are abbreviated: Official name abbreviated Origin of trust / who vouches ------------- ----------- ----------------------------- secure boot keys SB keys hardware keys (if present) bootloader bootloader SB keys kernel signer signer bootloader .builtin_trusted_keys builtin kernel signer .secondary_trusted_keys secondary builtin & (new in 5.18) machine .ima ima builtin & secondary .platform platform firmware, SB, MOK .machine machine MOK, management system In simplified story form, hardware keys authorize secure boot keys, which authorize the bootloader, which authorizes whoever signs the kernel, who authorizes the builtin keys, which (along with the machine keys) authorize the secondary keys, which (along with builtin) authorize the ima keys. The firmware, secure boot keys, or machine owner keys (MOK) authorize the platform keys. MOK or a management system authorizes the machine keys. Key usage and restrictions -------------------------- In addition to having different origins of trust, keys are used for different purposes: verifying signatures on kernel modules (code), on kexec'd kernel images (code), on data, and on other keys. See [1] for more details. Unfortunately, key usage restrictions are not consistently enforced throughout the kernel. For example, a key used to verify code might be used to verify data or other keys. Insufficient functionality -------------------------- Before the addition of the machine keyring, secondary keys were only authorized by builtin and other secondary keys. There was a well-defined, but inflexible source of trust. Multiple distros needed a way to load keys from sources unknown at kernel signing time. They used their own out-of-tree patches to load additional keys onto the secondary keyring. Today, the only way to *guarantee* proper enforcement of key usage and restrictions is to create a new keyring and write patches to limit its functionality. The platform keyring, used only for verifying kexec'd kernels, is a good example. Even then, current needs are not met. For example, one vendor wants to provide additional guidance such as, "Use key X1 only for verifying kernel modules from vendor X." Others want to restrict keys to those linked to a hardware root of trust. Additional problem ------------------ With the addition of the machine keyring, keys from a new source of trust can be added to the secondary keyring. Without proper enforcement of key usage and restrictions, those keys can be used for any purpose. Proposed solutions ------------------ 1. In the short term, load only CA keys onto the machine keyring and re-enable IMA. Define a kernel configuration option to prevent breakage. The kernel configuration option could either enable or disable CA-only keys. 2. Don't link the machine keyring to the secondary keyring. Just as there are limitations on usage of keys in platform, add limitations on keys in machine to a very specific stated purpose, clearly expressed in the cover letter and patch description, e.g., verifying kernel modules. 3. In the long term, work towards a) enforcement of key usage in the certificate, and b) implementing policy controls on keys. [1] https://static.sched.com/hosted_files/lssna2022/18/LSS%202022%20trust%20and%20keyrings.pdf ----- -Elaine Palmer, IBM Research
