Plan of action for Secure Boot support

[Florian Weimer]

* Ben Hutchings:

> However, there is now a blog post from Microsoft that supports what
> Matthew Garrett has been saying for a while - they may revoke the
> signature on a boot loader if signature verification is not extended to
> the kernel, including any mechanism to chain-load another kernel:
>
> http://blogs.msdn.com/b/windows_hardware_certification/archive/2013/12/03/microsoft-uefi-ca-signing-policy-updates.aspx
> (specifically point 5(b))
>
> This implies that when Secure Boot is enabled, only signed kernels and
> modules can be loaded and other features that allow code injection such
> as kexec, hibernation and /dev/mem must be disabled.

We also need to use an EV certificate in the shim—not just for
submission to Microsoft, but also for the certificate that signs GRUB
and the kernel (item 6 (a)).

The Terms & Conditions of existing EV code-signing CAs do not permit a
code-signing end-entity certificate to be used for signing another
certificate, so we'd directly have to embed the end-entity certificate
used to sign GRUB and the kernel into the shim—or we'd have to ship
the EV root CA, but that would extend complete trust to that CA.  If
we embed the end-entity certificate, we need to submit a new shim to
Microsoft for signing each time the certificate changes (say, because
the previous certificate expired after a year).

Furthermore, we need to store the keys for all EV certificates (both
the certificate used for submission, and the certificate embedded in
the shim) in devices that meet at least FIPS 140 Level 2.  Such
devices that are affordable, support secure, remote operation, and are
compatible with free software environments are difficult to find.
(But perhaps we can find a DD who agrees to keep the keys in his or
her home and manually signs our kernels, using Windows if necessary.)

I'm not sure if we can sign sid kernels because of the requirement to
sign production quality code only.

With KVM, we can boot another operating system after executing
unauthenticated (userspace) code, so the new policy seems to force us
to disable KVM per item 5 (b) (or extended Secure Boot to qemu-kvm,
which is practically impossible at present because we do not have a
signed userspace).  Obviously, one can still start a virtualized
environment without hardware support, and I don't know what this means
for compliance.

I wonder why Microsoft no longer wants to sign GPLv3 code (such as
GRUB 2).  It could be due to plans to make Secure Boot mandatory
eventually.  Right now, it is possible to comply with the GPLv3
license requirements because users can switch off Secure Boot, either
at the BIOS level or through the MokManager loophole.  This does not
affect us because we rarely ship hardware with Debian pre-installed,
and if we do, we can make use of the general GPLv3 opt-out clause.
But it would affect some of our users.

There is also a significant technical limitation: The current
shim/grub/kernel combination is totally untested as far as revocation
is concerned.  Fedora does not blacklist kernels with known
root-to-ring-0 escalation vulnerabilities.  This means that you can
just downgrade the kernel to a known-vulnerable version and lose all
protections allegedly provided by Secure Boot (as far as the Linux
side is concerned).  On the other hand, no one really wants to fix
this because it would mean that users cannot downgrade kernels anymore
to deal with regressions.

In short, I think it is very hard for us to comply with the new
Microsoft guidelines.  It is also politically problematic because once
we comply, Microsoft could try to claim that mandatory Secure Boot is
not locking out anyone (because it's not just Fedora anymore).

We could still do our own thing under a root we control, but then we
have to decide if we want to cross-certify everyone else.

We should probably continue the discussion on debian-project because
it's not just about the kernel or technical issues.