Bug#906124: Additional debug info

[Somebody else]

On Fri, Aug 17, 2018 at 4:42 PM Colin Watson <cjwatson at debian.org> wrote:
>
> On Fri, Aug 17, 2018 at 03:26:36PM +0200, Somebody else wrote:
> > Now, MY setup, which worked up to grub-efi 2.02+dfsg1-4, was such that
> > I removed all Microsoft-owned keys from my system and replaced them
> > with my own keys. Then I signed a GRUB2 standalone image (created via
> > grub-mkstandalone) and booted that from UEFI. A setup that can be
> > found on my GitHub https://github.com/jdelic/secureboot/. By setting
> > 'check_signatures=enforce' in grub-initial.cfg and bundling my own GPG
> > key, Grub would verify that *I* had signed the kernel image, not
> > Debian.
>
> I suspect that we'll need to change linuxefi to explicitly permit
> kernels that have been verified using the check_signatures mechanism.
> It's not such a common case, so nobody's done the work for it yet.
>
> > As far as I can tell right now, 2.02+dfsg1-5 added a patch
> > 'debian/patches/linuxefi_require_shim.patch' that requires the shim to
> > be present in the boot order.
>
> No, that change was added a long time ago.  The change that caused the
> symptoms you observe was the addition of
> debian/patches/linuxefi_disable_sb_fallback.patch.
>

Oooh, I think I understand now. Let me see if I can describe it in my
own words. Previously, the chain in my setup probably looked like
this:

* UEFI verifies standalone signed GRUB-EFI
* GRUB checks for secureboot and tries linuxefi instead of linux
* linuxefi fails, because no shim present
* 2.02+dfsg1-4 now fell back on "linux". This then ran with
"check_signatures=enforce" providing a chain of trust that provably
worked (I had tested this setup with modifying the kernel, initrd, and
signatures extensively, so I knew that it detected modifications
correctly)
* 2.02+dfsg1-5 however now returns an error if linuxefi fails.

So while my setup was probably secure (I based it off
https://ruderich.org/simon/notes/secure-boot-with-grub-and-signed-linux-and-initrd),
but this wasn't guaranteed. The current code now ensures that GRUB
won't continue booting if secureboot is enabled and a chain of trust
can't be established from the shim to the kernel. Correct?

In theory then, Grub could test if "check_signatures" is enabled and
then allow the boot process to proceed. As you wrote below, this would
require some "interesting" code layout. I can already see additional
problems cropping up, because, if you read the article I linked above,
the setup I'm using is already insecure unless the GRUB configuration
blocks "falling through" to a recovery shell. So in code checking
whether "other types of signatures are being enforced" is not
equivalent to "the chosen setup is secure against an attacker gaining
a shell and setting check_signatures to false". Or is linuxefi
vulnerable to the same setup (i.e. providing an attacker with an
unauthenticated recovery shell by "falling through" the default grub
config)?

[...]
> > So unless I'm totally misinterpreting the information available to me
> > (which is possible, since Grub's codebase and Debian's version of it
> > are not the best documented codebases ever), I think that this patch
> > to the best of my knowledge introduced an unnecessary restriction that
> > broke my setup and should probably be considered a bug :(.
>
> The new restriction to boot only signed kernels in SB mode is in general
> necessary to fit the generally-understood SB security model;
> unfortunately your custom setup sits in a corner case that we hadn't
> previously heard much about and so isn't handled right now.

Understood. If what I wrote above is correct then I probably should
just compile and ship my own shim for a trial run and probably stick
with that. I personally like GPG-signatures much better than the
sbsign-style signatures, if only because I assume that the gpg
--verify code is more battletested, but I can live with it if the
implementation is more secure in general against user error.