Re: [PATCH RFC v2 0/5] verifiers: Framework and EFI shim lock verifier

[Matthew Garrett <mjg59@srcf.ucam.org>]

On Fri, Aug 03, 2018 at 03:39:53PM +0200, Daniel Kiper wrote:

> Some verifiers, e.g. shim lock, may not be able to verify all file types, e.g.
> GRUB2 modules, on your own and would want to delegate verification to other
> verifiers, e.g. PGP. Currently this is not possible. So, I think that we should

If every verifier is called in turn, isn't this handled by having the 
shim interface return valid for all file types it doesn't verify?

> extend the interface with relevant functionality. However, this will not solve
> all problems. E.g. it is dangerous to load iorw or memrw modules, even if they
> are signed e.g. with PGP, if UEFI secure boot is enabled. So, I think that we
> should disable module loading if such verifiers are in use or provide
> a functionality which gives us a chance to black list some modules.

One option would be a secure boot verifier that just denies verification 
of all modules (or has some more complicated policy)?

> If TPM verifier is introduced then module loading order changes will change
> measurements. So, in this case maybe we should encourage users to use
> standalone GRUB2. Or enforce module loading order somehow. However, this
> can be difficult and not reliable.

Yeah, I think standalone images are going to be the right solution for 
most users here.

-- 
Matthew Garrett | mjg59@srcf.ucam.org