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.
Attachment:
signature.asc
Description: This is a digitally signed message part