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

[Philipp Hahn]

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.

@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