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

[David Howells]

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.

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.

David