[RFC PATCH 0/3] Add additional MOK vars
zohar at linux.ibm.com
Fri May 21 11:44:52 UTC 2021
[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.
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. 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.
 Perhaps extend the existing "ca_keys" boot command line option.
More information about the Linux-security-module-archive