RE: UEFI Revocation List being distributed by Debian
To the original conversation that started this, upstream fwupd decided
not to ship the updated database due to this discussion. The feature
that will use it will display an error message telling a user where
to fetch it from and manually install on their system instead to use the
feature.
> -----Original Message-----
> From: Florian Weimer <fw@deneb.enyo.de>
> Sent: Thursday, May 7, 2020 1:43 AM
> To: Paul Wise
> Cc: Limonciello, Mario; debian-legal
> Subject: Re: UEFI Revocation List being distributed by Debian
>
>
> [EXTERNAL EMAIL]
>
> * Paul Wise:
>
> > On Thu, 2020-05-07 at 07:26 +0200, Florian Weimer wrote:
> >
> >> It also has to be optional and disabled by default because a future
> >> dbx update may be specifically designed to stop Debian systems from
> >> booting. No Debian user will want to install such an update.
> >
> > Isn't the point of these updates to fix security issues, not to block
> > systems from booting?
>
> If Debian signatures are revoked, then the intent is to stop Debian
> from booting, for everyone. The main reason for doing this will
> likely be to protect users from harm that did not intent to run Debian
> at all, but there is no way to tell those users from everyone else.
>
Just to correct; it's not signatures that would be revoked but rather
hashes.
Due to the nature of
1) Being able to interchangeably use bootloaders and kernels from another
Linux based distribution
and
2) Debian closely following upstream both for kernel and bootloader
It's very unlikely that hashes would be revoked solely for Debian and
not every other Linux distribution that has a signed bootloader at the
same time in the event of a bootloader vulnerability of sufficient magnitude.
Furthermore I think your strong wording is an incorrect assumption
on the intent of revocation of hashes. The database is to ensure that
there are no known security vulnerabilities in any pieces that hurt the
ecosystem. Even without secure boot in the picture a security vulnerability
being found in the bootloader would likely warrant distributing an updated
bootloader image online updates and re-spinning installation media. This just
mandates it to use your computer with secure boot enabled in BIOS setup.
I don't feel this is unique to Debian in any way. The part that is missing
from Debian today is a method to distribute this updated database at the same
time as an updated bootloader.
> According to the signing policy, Debian signatures can be revoked if a
> vulnerable Debian kernel is used to kexec other operating systems in
> the wild, bypassing their security protections:
>
> | b. Developers might assume that secure boot security requirements
> | have been satisfied when their initial boot is complete. However,
> | if a secure boot system permits launch of another operating system
> | instance after execution of unauthenticated code, the security
> | guarantee of secure boot is compromised. If this vulnerability is
> | exploited, the submission might be revoked.
>
> <https://techcommunity.microsoft.com/t5/windows-hardware-
> certification/microsoft-uefi-ca-signing-policy-updates/ba-p/364828>
>
> I assume “exploited” here means “actual malware abuses signed code”,
> not harmless demonstration code.
Harmless demonstration code is just malware building blocks.
>
> In order reduce this risk, Debian would have to blacklist earlier
> kernels along with kernel updates that fix root-to-ring-0
> vulnerabilities (likewise for GRUB and shim). The signing policy
> actually requires this today. Quoting the same source:
>
> | b. Submitter must design and implement a strong revocation
> | mechanism for everything the shim loads, directly and subsequently.
>
> I do not know *any* Linux distribution that does this. Most system
> administrators would really dislike it if they could only boot one
> kernel version and have no way to downgrade if there is a kernel
> regression.
>
> (We should probably move this discussion to debian-project.)
It's also possible to publish a MokListX database update for this same
purpose.
Reply to: