Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot

[James Bottomley]

On Thu, 2018-08-16 at 13:13 +0100, David Howells wrote:
> Vivek Goyal <vgoyal@xxxxxxxxxx> wrote:
> 
> > Now this patch changed it to trusting builtin_trusted_keys by
> > default, and all the other keys go to secondary_trusted_keys
> > kerying. And that probably explains why it broke.
> > 
> > So checking for keys in both the keyrings makes sense to me.Â
> > 
> > I am wondering why did we have to split this keyring to begin
> > with.ÂSo there are use cases where we want to trust builtin keys
> > but not the ones which came from other places (UEFI secure boot db,
> > or user loaded one)?
> 
> IMA and the IMA authors.ÂÂThey want everything separated into
> separate keyrings out by source and usage as far as I can tell -
> though this just makes it harder to use things.

Hey, it's not just IMA people.  I've told you several times you can't
use the secure boot keys for any form of trust beyond boot, so if you
want to add them to the kernel they have to be in a lesser trusted
keyring.  Anyone who values their security wants to be very careful
what the UEFI keys are trusted for ... it's not just IMA signatures as
the module signing discussion shows.

Personally, I don't see any use for the UEFI keys in the kernel beyond
kexec (where you can actually get the key directly from the UEFI
variable), so I'd prefer not to load them and not to have a secondary
keyring.

> One advantage of splitting things, though, is that you don't lose the
> built-in keys if you load a conflicting one from another source.
> 
> One thing that's on my to-do list is to mark keys with the
> provenance, perhaps
> something like:
> 
> 	enum key_source {
> 	ÂÂÂÂÂkey_added_by_user,
> 	ÂÂÂÂÂkey_built_in_for_modsign,
> 	ÂÂÂÂÂkey_added_to_image,
> 	ÂÂÂÂÂkey_from_uefi_db,
> 	ÂÂÂÂÂkey_from_uefi_dbx,
> 	ÂÂÂÂÂkey_from_tpm,
> 	};
> 
> 	struct key {
> 		...
> 		enum key_source	source;
> 	};
> 
> Then:
> 
> Â(1) pass this information to LSMs to make use of
> 
> Â(2) Make the verification code take a bitmask of what keys are
> permitted for
> ÂÂÂÂÂthe task at hand.

Sounds reasonable,

James