UEFI Secure Boot and Ubuntu - implementation

[Jamie Strandboge]

On Mon, 2012-06-25 at 21:09 +0100, Matthew Garrett wrote:
> On Mon, Jun 25, 2012 at 03:01:50PM -0500, Jamie Strandboge wrote:
> 
> > At this point, because all the OS' stage 1 bootloaders (FLOSS and
> > non-FLOSS) are signed by the same authority, we are all are affected by
> > the others. It is clear that if there is a problem with DistroX's boot
> > loader, malware authors will just use DistroX's vulnerable boot loader
> > to attack DistroY and any other systems that don't yet have an update to
> > dbx (including DistroX itself). Obviously this is the purpose of dbx,
> > but dbx is only useful if the individual or OS vendor has a key in KEK
> > such that dbx can be updated.
> 
> Microsoft have volunteered to maintain dbx, so the absence of a KEK 
> isn't a problem - the Microsoft KEK will always be present. In the event 
> that hardware is shipped with a vendor KEK but no Microsoft KEK then the 
> vendor would have to take responsibility, but it seems likely that 
> that'll be a very small corner case.
...
> Again, this isn't a problem. It's trivial to just do this via dbx, as 
> above. My understanding is that you're planning on using the shim loader 
> I've been working on - it supports this functionality. There's no need 
> for a third party to be involved in any part of the process other than 
> providing the revocation update.

I admit I don't have all the most recent details on the shim loader (our
Foundations team is handling the implementation details)-- I see just
today some commits on adding black/white listing so maybe these are new
developments....

I was unaware that that Microsoft "volunteered to maintain dbx". Where
was this stated and how are they doing this exactly? How does an
individual/OS vendor go about "providing the revocation update" if
Microsoft is maintaining dbx? I was aware that Microsoft would provide
dbx updates in their security updates, but on a Fedora or Ubuntu system
that doesn't dual-boot, how is the update provided? Based on your
comment below, it sounds like the non-Windows OS vendor needs to provide
the update: upload the bad bootloader, get a signed-by-MS blob, update
dbx via some distro tool. In this scenario, how does Fedora obtain
updates to dbx for revoked Ubuntu binaries, and vice-versa (ie, to
prevent DistroX bootloader/kernel from being used on DistroY)? This
seems like it would get unwieldy in a hurry.

> > For these reasons, it seems clear to me that extending Secure Boot to
> > include a partially or fully attested boot by signing the kernel and
> > modules just doesn't seem to work well enough to justify the significant
> > inconvenience to the individual/OS vendor when the individual/OS vendor
> > doesn't have a key in KEK to control dbx.
> 
> I think you've based this on some misapprehensions. There's no need for 
> any additional significant inconenience for the vendor - they just need 
> to be able to provide exploitable binaries to Microsoft and ship dbx 
> updates via their update mechanism.

I maintain that even if Microsoft makes updates to dbx as painless as
possible, we are still relying on their system to work properly and in a
timely fashion. If we are signing our kernel, that means we will have to
rely on Microsoft for all kernel security updates.

While it sounds like dbx maintenance could be (partially) automated by
the distribution, there are still potential delays from the 3rd party
and the inconvenience for users having to deal with a locked down system
by default. Personally, I don't think signing the kernel and modules by
default provides enough benefit to warrant the compromises that must be
made. Obviously, it is worthwhile to protect early boot, and Ubuntu is
working to support using Secure Boot in accordance with the
specification. I also think that verifying the kernel, its modules and
farther up the stack as part of attested boot is also interesting and
something I would like to see supported in Ubuntu, but only as an opt-in
for enterprises and interested individuals, not in a general purpose
distribution.

-- 
Jamie Strandboge             | http://www.canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20120625/36954d4f/attachment.pgp>