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
signature.asc
Description: This is a digitally signed message part
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel