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

From: Mimi Zohar <zohar@linux.ibm.com>
To: Eric Snowberg <eric.snowberg@oracle.com>,
	keyrings@vger.kernel.org,
	linux-integrity <linux-integrity@vger.kernel.org>
Cc: David Howells <dhowells@redhat.com>,
	David Woodhouse <dwmw2@infradead.org>,
	dmitry.kasatkin@gmail.com, James Morris <jmorris@namei.org>,
	Jarkko Sakkinen <jarkko@kernel.org>,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	torvalds@linux-foundation.org,
	"Serge E . Hallyn" <serge@hallyn.com>,
	James Bottomley <James.Bottomley@HansenPartnership.com>,
	pjones@redhat.com, glin@suse.com,
	"konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
	Patrick Uiterwijk <patrick@puiterwijk.org>
Subject: Re: [RFC PATCH 0/3] Add additional MOK vars
Date: Fri, 21 May 2021 07:44:52 -0400	[thread overview]
Message-ID: <fd0e91c43cf0dc14aeeda4e7095416c77df0d0cc.camel@linux.ibm.com> (raw)
In-Reply-To: <4A887886-BDB2-4F88-9D83-73B9BC9E641F@oracle.com>

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