Messages in this thread | | | From | David Howells <> | Subject | Re: [PATCH] Fix kexec forbidding kernels signed with custom platform keys to boot | Date | Thu, 16 Aug 2018 13:13:30 +0100 |
| |
Vivek Goyal <vgoyal@redhat.com> 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
| |