On Fri, Aug 17, 2018 at 05:46:10PM +0200, Somebody else wrote: > On Fri, Aug 17, 2018 at 4:42 PM Colin Watson <cjwat...@debian.org> wrote: > > 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?
I may have missed the odd detail, but that seems like a fair summary. > In theory then, Grub could test if "check_signatures" is enabled and > then allow the boot process to proceed. Roughly, yes. It'd have to make sure that the "verify" module is loaded too in order to ensure that that's actually effective; and I think it might be a good idea to export a function from the verify module that allows other modules to query whether signature checking enforcement is enabled, rather than having to reimplement the environment variable parsing themselves (indeed, having linuxefi call a function from the verify module would be the easiest way to ensure that verify is loaded). But it shouldn't be too hard overall. > 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)? I think those are two slightly different security models, although they overlap. Simplifying wildly, the SB model requires that somebody can't stealthily install an unauthorised kernel on your system and have it boot without you knowing about it, while the check_signatures/passwords model ensures that GRUB can't do anything except what you configured it to do even in the face of an attacker with interactive boot-time access. Given enforcement of signed kernels, an attacker who gets a GRUB shell still can't defeat the SB model, because grub.cfg is already considered untrusted, and all they can do is load some other signed kernel and maybe extract some information from the system. Setting check_signatures=false wouldn't break this model, because then the next call to linuxefi would only be willing to load kernels authorised by shim (assuming that the check_signatures check is done on every call to linuxefi, as would be natural). check_signatures with superuser passwords is a stricter model in some ways: for instance, it would also prevent an attacker with interactive boot-time access from being able to extract information from the system using GRUB commands such as "cat", and it means that they can't use any dangerous commands that might accidentally have been built into the GRUB core image. In some environments that kind of hardening may well be a good idea. However, lacking it doesn't necessarily mean that you can break the SB security model. > > 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. I have no quarrel with the GPG approach; I just hadn't previously thought much about using it in combination with SB. I'd be happy to help you put a GRUB patch together to support it, if you like; you certainly seem to be in a good position to test it. -- Colin Watson [cjwat...@debian.org]
