On May 24, 2021, at 5:12 AM, Mimi Zohar [off-list ref] wrote:

On Sun, 2021-05-23 at 18:57 -0600, Eric Snowberg wrote:

quoted

quoted

On May 21, 2021, at 5:44 AM, Mimi Zohar [off-list ref] wrote:

On Thu, 2021-05-20 at 14:37 -0600, Eric Snowberg wrote:

quoted

quoted

On May 20, 2021, at 6:22 AM, Mimi Zohar [off-list ref] wrote:

quoted

quoted

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].

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.

quoted

quoted

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 [1]. 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.

Correct, it does not prevent an unknown public key from being loaded into 
a keyring. Shim prevents unknown public keys from being added. Only the 
machine owner with physical presence can make these changes.  All keys 
shim loads into the MOKList get measured on each boot.

If an unknown public key could be loaded into MOK, shim could boot any 
kernel signed with it as well.  This kernel could be changed to load 
anything into the kernel keyring. So, I struggle to understand the 
difference; isn’t this exactly the same threat?

If an end-user wanted to protect against either case, they would need 
to construct a measured boot attestation policy that included PCR14 and 
took the host out of service if the PCR values didn’t match up.

quoted

quoted

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.

[1] https://github.com/esnowberg/shim/commit/ee3961b503e7d39cae7412ddf4e8d6709d998e87#diff-b1dd148baf92edaddd15cc8cd768201114ed86d991502bc492a827c66bbffb69R259