Bug#906124: Additional debug info

[Colin Watson]

On Fri, Aug 17, 2018 at 05:46:10PM +0200, Somebody else wrote:
> On Fri, Aug 17, 2018 at 4:42 PM Colin Watson <cjwatson at 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                                       [cjwatson at debian.org]