From: Mimi Zohar <email@example.com>
To: Eric Snowberg <firstname.lastname@example.org>,
Cc: David Howells <email@example.com>,
David Woodhouse <firstname.lastname@example.org>,
email@example.com, James Morris <firstname.lastname@example.org>,
Jarkko Sakkinen <email@example.com>,
"Serge E . Hallyn" <firstname.lastname@example.org>,
James Bottomley <James.Bottomley@HansenPartnership.com>,
Patrick Uiterwijk <email@example.com>
Subject: Re: [RFC PATCH 0/3] Add additional MOK vars
Date: Mon, 24 May 2021 07:12:02 -0400 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On Sun, 2021-05-23 at 18:57 -0600, Eric Snowberg wrote:
> > On May 21, 2021, at 5:44 AM, Mimi Zohar <email@example.com> wrote:
> > On Thu, 2021-05-20 at 14:37 -0600, Eric Snowberg wrote:
> >>> On May 20, 2021, at 6:22 AM, Mimi Zohar <firstname.lastname@example.org> 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.
> Yes, I saw that patch. I view (which could be a mistake on my part)
> digital signature based IMA appraisal as an extension of a verified boot.
> Once a TPM is introduced, it is an extension of a measured boot. It seems
> like this patch is using measured boot to solve a problem that exists on
> the verified boot side. While it may be a good solution for someone using
> both measured boot and verified boot at the same time, not all machines or
> VMs contain a TPM.
True, the TPM is used as part of measured boot, but that doesn't
prevent it from being used in other capacities. In this case the TPM2
NV Index was used just to store a public key and safely used based on
TPM 2.0 rules.
> > Using MOK is a possible alternative, if it can be done safely.
> I do want to point out, in case this was missed, when the new MOK variable
> is set to trust the platform keyring, PCR14 gets extended . The UEFI BS
> var MokTPKState is mirrored to a freshly created UEFI RT var called
> MokTrustPlatform. The contents are extended into PCR14. This happens every
> time the system boots. The UEFI RT var does not persist across reboots, it
> is alway recreated by shim. The same thing happens with keys in the MOKList.
> Since the contents are mirrored, a key change can be detected on each boot.
> This makes it possible to use attestation to see if the system was booted
> with the proper variables set. For someone using measured boot, would this
> satisfy the requirement of safely protecting the system from a MOK update?
TPM based trusted keys can be sealed to a TPM PCR. Only if the PCRs
matched, is the private key unsealed. In that case, measuring
provides the trust for releasing the private key. In this case, just
measuring the UEFI MOK variable and key does not prevent an unknown
public key from being loaded onto a keyring. Once loaded it could be
used to verify any signed code's signature.
> > 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. 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.
>  https://github.com/esnowberg/shim/commit/ee3961b503e7d39cae7412ddf4e8d6709d998e87#diff-b1dd148baf92edaddd15cc8cd768201114ed86d991502bc492a827c66bbffb69R259
next prev parent reply other threads:[~2021-05-24 11:12 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
2021-05-24 0:57 ` Eric Snowberg
2021-05-24 11:12 ` Mimi Zohar [this message]
2021-06-01 15:24 ` Eric Snowberg
2021-05-24 10:09 ` Dr. Greg
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).