keyrings, key usage, and trust models

[Elaine Palmer <erpalmerny@gmail.com>]

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