On Tue, Jan 12, 2021 at 02:57:39PM +0000, David Howells wrote: > Eric Snowberg <eric.snowb...@oracle.com> wrote: > > > > On Dec 10, 2020, at 2:49 AM, David Howells <dhowe...@redhat.com> wrote: > > > > > > Eric Snowberg <eric.snowb...@oracle.com> wrote: > > > > > >> 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? /Jarkko
