On Wed, Jan 13, 2021 at 05:11:10PM -0700, Eric Snowberg wrote: > > > On Jan 13, 2021, at 1:41 PM, Jarkko Sakkinen > > <jarkko.sakki...@linux.intel.com> wrote: > > > > 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? > > Today, DB and MOK certs go into the platform keyring. These certs are only > referenced during kexec. They can’t be used for other things like validating > kernel module signatures. If we follow the same pattern, the DBX and MOKX > entries > in the blacklist keyring should only impact kexec. > > Currently, Mickaël Salaün has another outstanding series to allow root to > update > the blacklist keyring. I assume the use case for this is around certificates > used > within the kernel, for example revoking kernel module signatures. The > question I have > is, should another keyring be introduced? One that carries DBX and MOKX, > which just > correspond to certs/hashes in the platform keyring; this keyring would only be > referenced for kexec, just like the platform keyring is today. Then, the > current > blacklist keyring would be used for everything internal to the kernel.
Right, I'm following actively that series. Why couldn't user space drive this process and use that feature to do it? /Jarkko
