[RFC PATCH 0/3] Add additional MOK vars

[Mimi Zohar]

[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 <zohar at linux.ibm.com> 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.
 
thanks,

Mimi

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