[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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx/ [2] Perhaps extend the existing "ca_keys" boot command line option.
