Re: linux-next: UEFI Secure boot lockdown patchset

[Mimi Zohar <zohar@linux.vnet.ibm.com>]

On Tue, 2018-05-01 at 22:32 +0000, Matthew Garrett wrote:
> On Tue, May 1, 2018 at 3:21 PM Mimi Zohar <zohar@linux.vnet.ibm.com> wrote:
> 
> > On Tue, 2018-05-01 at 21:59 +0000, Matthew Garrett wrote:
> > > Oh, is kexec verified off the _module keyring? We still end up with the
> > > problem that distributions don't have a mechanism to ship IMA signatures
> > > yet, but that avoids the user modification problem. I've just posted a
> > > patchset to debian-dpkg, we'll see how that goes.
> 
> > I'm not aware of a _module keyring.  With IMA-appraisal, the signature
> > verification of the kernel image (kexec_file_load) uses the trusted
> > IMA keyring.  Nayna Jain posted a patch that defines a new platform
> > keyring[1], which would only be used to validate the kernel image and
> > initramfs signatures.
> 
> INTEGRITY_KEYRING_MODULE is defined, but doesn't appear to be used
> anywhere. Odd. Anyway, distributions are unlikely to ship with
> CONFIG_INTEGRITY_TRUSTED_KEYRING since it makes it impossible for users to
> determine which set of IMA or EVM signatures they want to trust. So if
> validation is against the IMA keyring rather than builtin_trusted_keys,
> it's going to be possible for users to extend the set of trusted keys. If
> CONFIG_KEXEC_BZIMAGE_VERIFY_SIG is set then the kernel seems to do the
> right thing here, but it's not clear to me how that's supposed to interact
> with IMA?

>From your description, whatever keys the distros are loading onto the
builtin_trusted_keys keyring for verifying the kexec kernel image,
could just as easily be added to the IMA trusted keyring
(CONFIG_INTEGRITY_TRUSTED_KEYRING).  I don't see the difference.

Loading other keys requires reserving memory for a local CA public
key.

Mimi