* Re: keyrings, key usage, and trust models
2022-07-20 18:43 ` keyrings, key usage, and trust models Elaine Palmer
@ 2022-07-21 22:53 ` Eric Snowberg
2022-09-28 5:59 ` joeyli
1 sibling, 0 replies; 3+ messages in thread
From: Eric Snowberg @ 2022-07-21 22:53 UTC (permalink / raw)
To: Elaine Palmer
Cc: linux-integrity@vger.kernel.org, keyrings@vger.kernel.org,
Dimitri Ledkov, Joeyli, Nayna Jain, George Wilson, Mimi Zohar,
jarkko Sakkinen, Kanth Ghatraju, Konrad Wilk
> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: keyrings, key usage, and trust models
2022-07-20 18:43 ` keyrings, key usage, and trust models Elaine Palmer
2022-07-21 22:53 ` Eric Snowberg
@ 2022-09-28 5:59 ` joeyli
1 sibling, 0 replies; 3+ messages in thread
From: joeyli @ 2022-09-28 5:59 UTC (permalink / raw)
To: Elaine Palmer
Cc: linux-integrity, keyrings, Dimitri Ledkov, Eric Snowberg,
Nayna Jain, George Wilson, Mimi Zohar
Hi,
On Wed, Jul 20, 2022 at 02:43:54PM -0400, Elaine Palmer 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.
>
There is a case where the platform manufacturer is also the machine
ower. Is it possible that they use keys in db as mok?
On the other hand, why kernel only allows keys in db for kexec? Is it
because UEFI spec says db is the signature store only for secure boot?
Thanks a lot!
Joey Lee
^ permalink raw reply [flat|nested] 3+ messages in thread