Plan of action for Secure Boot support

[Ben Hutchings]

On Wed, 2014-01-08 at 08:31 +0100, Florian Weimer wrote:
> * 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).

Presumably actual code signatures never expire (or rather, expiry should
not be checked) - as that would mean mandatory upgrades just to keep a
machine bootable.  CA certificates just need to be updated so they are
valid at the point in time they make a signature, right?

> 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.

testing/unstable is a rolling beta test for the next stable release; I
would have thought that was still 'production' in MS's terms.

experimental maybe shouldn't be signed.

> 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).

MS can go and stick their collective head in a blender if they expect us
to do that.

[...]
> 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.

Well, that would be almost all of them, right?

> 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.

I expect MS doesn't blacklist their old kernel versions, for exactly the
same reason.  Or do they?

> 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).

Because there are no Linux distributions made by anyone but RH, SUSE,
Canonical and Debian?

> 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.

Right.

Ben.

-- 
Ben Hutchings
Any smoothly functioning technology is indistinguishable from a rigged demo.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 828 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-grub-devel/attachments/20140108/823e5c69/attachment.sig>