On Fri, Aug 17, 2018 at 2:25 PM Ian Campbell <i...@debian.org> wrote: > > On Fri, 2018-08-17 at 10:22 +0200, Somebody else wrote: > > Any pointers? > > Have you seen https://wiki.debian.org/SecureBoot ? I'm not involved in > that effort but AIUI it describes the plan for what (and why) is going > through at the moment WRT enabling secure boot out of the box in Debian > (which, also AIUI, is in line with how other distros are doing things). >
Yes, I am familiar with this wikipage. And yes, this is in line with what other Distros are doing. In summary: To enable secureboot out of the box for systems shipped with Microsoft's keys in the UEFI, Debian ships a Microsoft-signed "shim bootloader" (contained in the package 'shim-signed') which loads a Debian-signed GRUB2, which loads a Debian-signed vmlinuz and initrd. 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. This is arguably more secure than the Microsoft-Debian approach as it prevents evil maid attacks by attackers who have either gained control of the Debian keys or control of the Microsoft keys. 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. by calling 'grub_efi_locate_protocol'. This broke my secureboot setup, because I'm not using the shim. My setup also doesn't require me to recompile any software. Using the shim however, requires me to compile my own version to embed my own public key into it. I also fail to see how this aids security. It's also worth pointing out that the patch in question contains the following metadata: >From 90b80a94103bece12cd80e99e71ff7ab75a66e0b Mon Sep 17 00:00:00 2001 From: Colin Watson <cjwat...@ubuntu.com> Date: Mon, 13 Jan 2014 12:13:19 +0000 Subject: Make linuxefi refuse to boot without shim This is only intended as a temporary measure. Forwarded: not-needed Last-Update: 2013-01-29 Patch-Name: linuxefi_require_shim.patch --- grub-core/loader/i386/efi/linux.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) [...] which is strange, because it's dated to 2014 and it was either just included in the Debian build, or some other patch had another side-effect that broke my setup in conjunction with this patch. In any case, using the log messages that I posted already, I know that this patch's changes are where the signature validation now fails on my system. It's also supposedly a "temporary" change that seems to have been around for a long time, but no context for it is provided. 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 :(. I was hoping that the maintainer could shed light on what's going on there.
