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

[Luca Boccassi]

On Mon, 2018-04-16 at 17:16 +0200, Philipp Hahn wrote:
> Hello,
> 
> Am 15.04.2018 um 23:03 schrieb Steve McIntyre:
> > On Thu, Apr 12, 2018 at 05:10:38PM +0100, Luca Boccassi wrote:
> > > 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.
> 
> ...
> > > > 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.
> 
> FYI: We (Univention) have been running with "linux" removed for >2
> years.
> 
> > > 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.
> 
> I see 2 use-cases here:
> 
> 1. make it as easiest as possible to install Debian even on systems
> where Secure Boot is enabled by default by providing a signed GRUB
> which
> loads anything.
> 
> 2. have a more secure setup where everything must be signed.
> 
> We chose to be on the save side and thus removed "linux". But you
> patch
> seems to be small enough to verify and actually looks quite nice:
> With
> it both "linux" and "linuxefi" can be used, which has an appeal.
> 
> So I'm okay to switch to your implementation.

Great, thanks! (but please note that the patch is from HPE and the
original submitter of this ticket, not myself :-) )

> @steve: I'm currently busy with work and family and don't have that
> much
> time until next weekend. I havenn't yet checked back for the status
> of
> the signing box, but how do you want to proceed with GRUB: I haven't
> yet
> done a complete test build of my patched packages with a self-created
> set of key to check that everything work as expected. Shall we
> continue
> working on my GIT repo or how do you want to get the required changed
> in
> your repo?
> 
> Thanks in advance and thanks to everyone working on this.
> Philipp

The Ubuntu folks have quite a lot of additional grub + secureboot
patches:

https://git.launchpad.net/~ubuntu-core-dev/grub/+git/ubuntu/tree/debian/patches/series?h=ubuntu

What are the chances that efforts could be combined? Otherwise we'll
end up facing the same bugs that they already fixed [1].

For what it's worth, I've been shipping our downstream at $work with
those patches as well.

-- 
Kind regards,
Luca Boccassi

[1] I know I have already mentioned it a few times, but those patches
include the fix for https://bugzilla.redhat.com/show_bug.cgi?id=1418360
which completely breaks the kernel lockdown functionality.
-------------- 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://alioth-lists.debian.net/pipermail/pkg-grub-devel/attachments/20180417/a9906b33/attachment.sig>