Vivek Goyal <vgo...@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
