Re: [RFC PATCH 0/3] Add additional MOK vars

Mimi Zohar
2021-05-21T11:45:37Z

[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@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.