Bug#820129: grub2: Disallow booting unsigned kernels when Secure Boot is enabled

Thu Apr 12 17:10:38 BST 2018

On Thu, 2018-04-12 at 15:58 +0100, Steve McIntyre wrote:
> [ Note cc to the d-efi list. SB is finally in progress after last
>   week's sprint! ]
> 
> Very belated, it's time we discussed this.
> 
> On Tue, Apr 05, 2016 at 11:17:24AM -0700, Linn Crosetto wrote:
> > Package: grub2
> > Version: 2.02~beta2-36
> > Severity: wishlist
> > Tags: patch
> > 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > The current code in 2.02~beta2-36 will silently fall back to
> > calling
> > ExitBootServices() and booting an unsigned kernel if signature
> > verification
> > fails.
> > 
> > As a part of support for UEFI Secure Boot in Debian (820036) change
> > the boot
> > to fail if signature verification fails.
> > 
> > I have attached a trivial patch for this change. Thanks!
> > 
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1
> > 
> > iQIcBAEBAgAGBQJXBAE0AAoJEF/3aG7d/FTWDh4P/ja6Qa0JRr2bIDj+I+sihFmJ
> > fIHVItLpMEU5hrKnpkRas7GflntzfpEObqUmzPLTRsrA1WobEyZDfNJUOonvEojR
> > atccbvjShxNJIZFCr+W8mGh23+Xv+4VFVJ9f2jd+2sOlmViGyM88rDLOZN69vwIe
> > 9+GbTY6Ha3PifVDwLXvNH0cNiInt8uPbPnFOKwAcwSqFncyq5mfpCroLIqgfR5Dv
> > ImROn7to4iurho3MOidJ0gRJm17mcPjzQAyX/Wh2asSiUMx2cIVrkfcSqoeb6W3L
> > sXytfIwMf3YzY+eLEpsTZDYhmxrJGMa9uQ+Ryg1ZCQI0uI/n3We7cXnukofcM+Of
> > sAtETJvr8SYrF5J/v7XafbEKXr64jV7wEEk97kDA+YGdw7nR1Y0UeX3W3AJCuOeo
> > /KF75oIKJrYbRLymT701RwjArKD2wXYDTzmvnQKiTBc4sPofnr+nJIUOGvZ8Tn8O
> > D/vI8PZKStsZ4cuABkiHEmA3y6zlVtJEkS+OGktNWrugNBJXGWHs6AHGjIIGenTQ
> > 8FPeNrC01DHf+170iV/0PXGLfJKn037y9JSDaZXuZkAsSrqmQENLKzOv9ee4QSsm
> > UmalPiqKkyeZRQna7ZDK+LwB8yf02applIzsQcFuF/RahZdgLhwl42doC7LgjpYI
> > wN0JD88AfHJAuUtwbpxc
> > =fkO9
> > -----END PGP SIGNATURE-----
> > > From 52de74c85ef6a9aca426d9de8f188fe92241aff6 Mon Sep 17 00:00:00
> > > 2001
> > 
> > From: Linn Crosetto <linn at hpe.com>
> > Date: Tue, 5 Apr 2016 11:49:05 -0600
> > Subject: [PATCH] Disallow unsigned kernels if UEFI Secure Boot is
> > enabled
> > 
> > If UEFI Secure Boot is enabled and kernel signature verification
> > fails, do not
> > boot the kernel. Before this change, if kernel signature
> > verification failed
> > then GRUB would fall back to calling ExitBootServices() and
> > continuing the
> > boot.
> > 
> > Patch-Name: linuxefi_disable_sb_fallback.patch
> > 
> > Signed-off-by: Linn Crosetto <linn at hpe.com>
> > ---
> > grub-core/loader/i386/linux.c | 8 +++-----
> > 1 file changed, 3 insertions(+), 5 deletions(-)
> > 
> > diff --git a/grub-core/loader/i386/linux.c b/grub-
> > core/loader/i386/linux.c
> > index 2380642..e2e26dd 100644
> > --- a/grub-core/loader/i386/linux.c
> > +++ b/grub-core/loader/i386/linux.c
> > @@ -696,10 +696,8 @@ grub_cmd_linux (grub_command_t cmd
> > __attribute__ ((unused)),
> >   using_linuxefi = 0;
> >   if (grub_efi_secure_boot ())
> >     {
> > -      /* Try linuxefi first, which will require a successful
> > signature check
> > -	 and then hand over to the kernel without calling
> > ExitBootServices.
> > -	 If that fails, however, fall back to calling
> > ExitBootServices
> > -	 ourselves and then booting an unsigned kernel.  */
> > +      /* linuxefi requires a successful signature check and then
> > hand over
> > +	 to the kernel without calling ExitBootServices. */
> >       grub_dl_t mod;
> >       grub_command_t linuxefi_cmd;
> > 
> > @@ -721,7 +719,7 @@ grub_cmd_linux (grub_command_t cmd
> > __attribute__ ((unused)),
> > 		  return GRUB_ERR_NONE;
> > 		}
> > 	      grub_dprintf ("linux", "linuxefi failed (%d)\n",
> > grub_errno);
> > -	      grub_errno = GRUB_ERR_NONE;
> > +	      goto fail;
> > 	    }
> > 	}
> >     }
> 
> This looks like one way of doing this. Philipp Hahn is suggesting
> that
> we just don't include the "linux" module in our signed grub
> build. That's simpler, but potentially causes problems elsewhere,
> e.g. "it gets a bit nasty to try and dynamically switch between linux
> and linuxefi in live-build". So, let's discuss - we need to agree our
> policy and decide the best mechanism here. Go...!

The issues I see is that until now pretty much everywhere "linux" is
used in grub.cfg.

This can be solved easily, and indeed Philipp has already done it, for
local installations - the problems arise when building images.

At least in live-build (not sure about debootstrap/live-wrapper?),
users can provide their own grub.cfg. Personally I've never seen anyone
use anything but "linux" in the menuentry (eg: Kali [2]).

So I'd need to do something like this [1] in live-build:

sed -i "s|linux\(\s\+/\w\+/vmlinuz\)|linuxefi\1|" \
    binary/boot/grub/grub.cfg
sed -i "s|initrd\(\s\+/\w\+/initrd\)|initrdefi\1|" \
    binary/boot/grub/grub.cfg

With the risk of randomly breaking with weird user's grub.cfg :-/

I'd really like to make the process as transparent as possible for
users, as there are already enough hoops to jump through as-is to get
secure boot working.

I have been using the patch from this bug in production for about a
year as an alternative in the downstream distro at $work, and it seems
to work fine.

On the other hand, I imagine it's easier to verify that nothing is
broken by removing the "linux" module rather than using this patch. So
there's the other side of the coin.

-- 
Kind regards,
Luca Boccassi

[1] https://salsa.debian.org/bluca/live-build/commits/linuxefi
[2] http://git.kali.org/gitweb/?p=live-build-config.git;a=blob;f=kali-config/common/bootloaders/grub-pc/grub.cfg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-grub-devel/attachments/20180412/759248bb/attachment.sig>