All of
 help / color / mirror / Atom feed
From: Elaine Palmer <>
	Dimitri Ledkov <>,
	Joeyli <>, Eric Snowberg <>,
	Nayna Jain <>,
	George Wilson <>,
	Mimi Zohar <>
Subject: keyrings, key usage, and trust models
Date: Wed, 20 Jul 2022 14:43:54 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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.



-Elaine Palmer, IBM Research

       reply	other threads:[~2022-07-20 18:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2022-07-20 18:43 ` Elaine Palmer [this message]
2022-07-21 22:53   ` keyrings, key usage, and trust models Eric Snowberg
2022-09-28  5:59   ` joeyli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.