Bug#906124: Additional debug info

[Vladislav Yarmak]

Hello,

Today I also stumbled upon this bug right after Debian 10 release.

First, I should explain why I consider setup with own EFI keys and PGP
signatures not as an exotic configuration but, rather, as the only
feasible use of Secure Boot.

Current chain consisting of UEFI SB -> shim -> grub -> kernel does not
prevent attacker from running untrusted code because initramdrive and
grub config is not covered by signature. Indeed, attacker absolutely
has no need to mess with kernel while he can completely replace
operating system on computer and implement any behavior he wants.
Silent sniffing of LUKS keys or adding own passphrase after decrypt is a
good example. One doesn't even need to have programming skills for
this: it's simple as unpack ramdrive, add file to /scripts/local-top,
pack it again and it's done.

More than that, final destination of a boot chain is user specific, so
it is impossible to restrict it with universal signed images. In
order to resolve that, user generated signature has to be introduced.
MOK keys may serve that purpose. But since this moment we don't
actually need any of vendor keys, we can put trust in our keys only.

Until entire boot chain is protected with signatures, Secure Boot is a
snakeoil. For this reason I maintain toolkit for automated deployment
of full boot chain
signature: https://github.com/Snawoot/linux-secureboot-kit
It works on wide variety of distros, and it worked on Debian Buster
weeks ago, before it's release.

While it is still possible to roll own shim and sign kernel with own
key, it requires to modify file which belongs to a distro package, so
it is undesirable. GPG approach uses detached signatures and doesn't
require to touch distro files. Also, shim is just unnecessary in this
case.

In the end, this Debian patch to grub contributes to false security
approach and cuts user from normal use of GRUB functionality. It's
clearly a security issue. If no proper solution appeared year
afterwards, probably it is worth to consider rollback of this patch.
So I'm eager to ask: is there any specific plans about this bug?

-- 
Best Regards,
Vladislav Yarmak