archive mirror
 help / color / mirror / Atom feed
From: Mimi Zohar <>
To: Eric Snowberg <>,,
	linux-integrity <>
Cc: David Howells <>,
	David Woodhouse <>,, James Morris <>,
	Jarkko Sakkinen <>,,,,
	"Serge E . Hallyn" <>,
	James Bottomley <>,,,
	"" <>,
	Patrick Uiterwijk <>
Subject: Re: [RFC PATCH 0/3] Add additional MOK vars
Date: Fri, 21 May 2021 07:44:52 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[Cc'ing Patrick Uiterwijk]

On Thu, 2021-05-20 at 14:37 -0600, Eric Snowberg wrote:
> > On May 20, 2021, at 6:22 AM, Mimi Zohar <> wrote:

> > I really do understand the need for extending the root of trust beyond
> > the builtin keys and allowing end user keys to be loaded onto a kernel
> > keyring, but it needs to be done safely.  The first step might include
> > locally signing the MOK keys being loaded onto the secondary keyring
> > and then somehow safely providing the local-CA key id to the kernel.
> If the machine owner and Linux distributor are independent of one another,
> I don’t see how MOK key signing could work.  There wouldn’t be a way for
> the kernel to verify the end-user supplied signed MOK key.  An end-user 
> choosing a Linux distro is trusting the company/organization building the 
> kernel, but the trust doesn’t go the other way.  Do you have a solution 
> in mind on how this would be possible? If you do, I’m happy to move in
> a different direction to solve this problem.

We are working with the distros to address this problem.  The first
attempt at extending the secondary keyring's root of trust relied on a
TPM2 NV Index[1].

Using MOK is a possible alternative, if it can be done safely.  For
example, if the boot command line could be protected from modification,
the end-user could enroll a key in MOK and identify the specific MOK
key on the boot command line[2].  The boot command line would then
become an additional root of trust source.

The root of trust for loading keys on the different trusted keyrings
are self documenting -  restrict_link_by_builtin_trusted,
restrict_link_by_builtin_and_secondary_trusted().  A new function would
need to be defined to include the boot command line as a new or
additional root of trust source.


[2] Perhaps extend the existing "ca_keys" boot command line option.

  reply	other threads:[~2021-05-21 11:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-17 22:57 [RFC PATCH 0/3] Add additional MOK vars Eric Snowberg
2021-05-17 22:57 ` [RFC PATCH 1/3] keys: Add ability to trust the platform keyring Eric Snowberg
2021-05-20 15:59   ` Jarkko Sakkinen
2021-05-17 22:57 ` [RFC PATCH 2/3] keys: Trust platform keyring if MokTrustPlatform found Eric Snowberg
2021-05-17 22:57 ` [RFC PATCH 3/3] ima: Enable IMA SB Policy if MokIMAPolicy found Eric Snowberg
2021-05-19  7:55 ` [RFC PATCH 0/3] Add additional MOK vars Jarkko Sakkinen
2021-05-19 14:32 ` Mimi Zohar
2021-05-19 22:04   ` Eric Snowberg
2021-05-20 12:22     ` Mimi Zohar
2021-05-20 20:37       ` Eric Snowberg
2021-05-21 11:44         ` Mimi Zohar [this message]
2021-05-24  0:57           ` Eric Snowberg
2021-05-24 11:12             ` Mimi Zohar
2021-06-01 15:24               ` Eric Snowberg
2021-05-24 10:09         ` Dr. Greg

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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).