Bug#820129: This is not a bug, but a feature
Helen Koike
helen.koike at collabora.com
Mon Apr 17 13:01:34 UTC 2017
On 2017-01-31 03:40 PM, Linn Crosetto wrote:
> On Thu, Dec 08, 2016 at 04:44:18PM +0100, Andreas Heinlein wrote:
>> I do not think this should be done, it would make it difficult if not
>> impossible to boot custom kernels. For your own use, you could always
>> build your own signed kernel and add the signing key to the UEFI
>> firmware, or turn off SecureBoot altogether.
>> However, for authors of Debian-based live systems like I am
>> (www.discreete-linux.org), we need a way that will boot the live system
>> on as many computers and platforms as possible without user interaction,
>> including those users which regulary use only windows, and including
>> platforms like Intel-based Tablets/Detachables which often do not allow
>> to turn off Secureboot. Our live system requires a special kernel to
>> work, it cannot work with any generic kernel/initrd signed by Debian.
>>
>> UEFI/SecureBoot specs do not require to keep the chain of signatures
>> through to the kernel/initrd, it is optional. There should at least be a
>> choice by providing two packages, one which allows booting unsigned
>> kernels and one which doesn't. Or we can find a way for projects to get
>> their kernels and/or own grub signed by Debian.
If secure boot is enabled then no untrusted system should be allowed to
run. If you need to run a custom kernel when Secure Boot is enabled that
doesn't require user interaction, then you can make your system
trustworthy by getting your own shim signed with your own embedded
certificated that will allow booting any custom grub2, then it doesn't
need to be signed by Debian, which make sense to me as custom images are
not officially part of Debian, thus not officially trusted by the Debian
community.
I don't think we should have two types of packages to allow booting
unsigned and signed kernels.
>
> Without verifying the kernel, the additional security features in the kernel
> become largely useless and we lose much of the value that a root of trust
> can provide. Note that this patch only affects systems with UEFI Secure Boot
> enabled.
>
> To allow boot without user interaction on a system with Secure Boot enabled,
> you could build shim with your key and get it signed.
>
ack
More information about the Pkg-grub-devel
mailing list