On Fri, Jan 15, 2021 at 09:49:02AM -0700, Eric Snowberg wrote:

quoted

On Jan 15, 2021, at 2:15 AM, Jarkko Sakkinen [off-list ref] wrote:

On Wed, Jan 13, 2021 at 05:11:10PM -0700, Eric Snowberg wrote:

quoted

quoted

On Jan 13, 2021, at 1:41 PM, Jarkko Sakkinen [off-list ref] wrote:

On Tue, Jan 12, 2021 at 02:57:39PM +0000, David Howells wrote:

quoted

Eric Snowberg [off-list ref] wrote:

quoted

quoted

On Dec 10, 2020, at 2:49 AM, David Howells [off-list ref] wrote:

Eric Snowberg [off-list ref] wrote:

quoted

Add support for EFI_CERT_X509_GUID dbx entries. When a EFI_CERT_X509_GUID
is found, it is added as an asymmetrical key to the .blacklist keyring.
Anytime the .platform keyring is used, the keys in the .blacklist keyring
are referenced, if a matching key is found, the key will be rejected.

Ummm...  Why this way and not as a blacklist key which takes up less space?
I'm guessing that you're using the key chain matching logic.  We really only
need to blacklist the key IDs.

I implemented it this way so that certs in the dbx would only impact 
the .platform keyring. I was under the impression we didn’t want to have 
Secure Boot UEFI db/dbx certs dictate keyring functionality within the kernel
itself. Meaning if we have a matching dbx cert in any other keyring (builtin,
secondary, ima, etc.), it would be allowed. If that is not how you’d like to 
see it done, let me know and I’ll make the change.

I wonder if that is that the right thing to do.  I guess this is a policy
decision and may depend on the particular user.

Why would you want to allow dbx entry in any keyring?

Today, DB and MOK certs go into the platform keyring.  These certs are only
referenced during kexec.  They can’t be used for other things like validating
kernel module signatures.  If we follow the same pattern, the DBX and MOKX entries
in the blacklist keyring should only impact kexec. 

Currently, Mickaël Salaün has another outstanding series to allow root to update 
the blacklist keyring.  I assume the use case for this is around certificates used 
within the kernel, for example revoking kernel module signatures.  The question I have
is, should another keyring be introduced?  One that carries DBX and MOKX, which just
correspond to certs/hashes in the platform keyring; this keyring would only be
referenced for kexec, just like the platform keyring is today. Then, the current
blacklist keyring would be used for everything internal to the kernel.

Right, I'm following actively that series.

Why couldn't user space drive this process and use that feature to do it?

I could see where the user would want to use both. With Mickaël Salaün’s
series, the blacklist keyring is updated immediately.  However it does
not survive a reboot.  With my patch, the blacklist keyring is updated
during boot, based on what is in the dbx. Neither approach needs a new 
kernel build.

I don't want to purposely challenge this, but why does it matter
that it doesn't survive the boot? I'm referring here to the golden
principle of kernel defining a mechanism, not policy. User space
can do the population however it wants to for every boot.

E.g. systemd service could do this.

What am I missing here?

/Jarkko