On Fri, Aug 17, 2018 at 4:42 PM Colin Watson <cjwat...@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.
