[Cc'ing Patrick Uiterwijk]

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

quoted

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

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

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.
 
thanks,

Mimi

[1] https://lore.kernel.org/linux-integrity/20210225203229.363302-1-patrick@puiterwijk.org/ (local)
[2] Perhaps extend the existing "ca_keys" boot command line option.