[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-keyrings
Subject:    Re: keyrings, key usage, and trust models
From:       Eric Snowberg <eric.snowberg () oracle ! com>
Date:       2022-07-21 22:53:07
Message-ID: 8BB9D406-0394-4E2E-9B84-4A320AFDBDC4 () oracle ! com
[Download RAW message or body]



> On Jul 20, 2022, at 12:43 PM, Elaine Palmer <erpalmerny@gmail.com> wrote:
> 
> 
> 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.

As you are aware, 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 allowed the system 
owner to add their own IMA CA through the MOK.

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.

My concern in only allowing CA keys into the machine keyring is distros will 
view this as a regression and go back to having to carry another out of tree 
patchset.  It will break what has worked in their distro for years.  CA keys 
have never been necessary for signing a key used  to sign their kernel 
module. The end-user will now need to enroll two keys.  First the CA
Key into the MOK and then the leaf cert into the secondary trusted keyring.

> 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

This is the path I started down with this series [1]. 

It continues to load all kernel compiled-in keys into the builtin keyring 
(these keys may or may not be a CA).  It also continues to load all MOK 
keys into the machine keyring (again, these keys may or may not be a 
CA).  It treats these keys equally, independent from their original source.  
Both builtin and machine keys are parsed to see if keyCertSign is set.  
The CA flag is checked and the key is validated to be properly self signed.  
If all these conditions are met, a new ROT flag is set.  I know Mimi didn't 
like the naming of this flag.  With any X.509 cert, most of the information is 
thrown away in the kernel after it is parsed. Very few pieces of the certificate 
are left in tact after they are loaded into a keyring.  That is why this new flag 
was introduced. I tried to come up with a term that was generic enough to be 
used by all types of public keys and not be X.509 specific.  The flag may also 
be set if a properly defined intermediate CA is found.  

Afterwards a new link restriction is introduced.  The first keyring to use this 
restriction is the IMA keyring.  Keys added to the IMA keyring must pass the 
new restriction test which validates the leaf cert can be vouched for by any 
key containing the new ROT flag.

If this approach is to be continued, I'm certainly open to renaming the flag.  Other 
flags could also be added, for example if the usage is digitalSignature, this could 
be enforced as well. By adding these flags, it doesn't break existing code in the 
kernel.  The public key doesn't need to be changed to keep a large quantity of 
X.509 specific data.  It also allows key usage to be slowly introduced into the 
kernel without breaking existing distros. 

I would like to know if an approach similar to this would be considered.  

[1] https://patchwork.kernel.org/project/keyrings/cover/20220406015337.4000739-1-eric.snowberg@oracle.com/#24808831



[prev in list] [next in list] [prev in thread] [next in thread]