On Mon, 2012-06-25 at 22:41 +0100, Matthew Garrett wrote: > On Mon, Jun 25, 2012 at 04:26:20PM -0500, Jamie Strandboge wrote: > > > I was unaware that that Microsoft "volunteered to maintain dbx". Where > > was this stated and how are they doing this exactly? > > This was discussed at the last plugfest. > > > How does an individual/OS vendor go about "providing the revocation > > update" if Microsoft is maintaining dbx? > > We're planning on going over the fine details in Redmond next month. > > > 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. > > dbx updates will be centralised - a flawed Ubuntu binary is as much a > threat to Windows as it is to Linux. Vendors just need to push out any > dbx updates via their own update mechanism (so apt, in your case).
Understood (and what I was getting at with my question). This is interesting. I'd be curious what protections are in place to keep someone from blacklisting another vendor's binaries (presumably vendors could only blacklist binaries previously signed by themselves). > > 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. > > The benefits of signing purely a bootloader are minimal - bootloaders > that load unsigned code will be perfectly willing to set up a secondary > UEFI environment and then launch another bootloader that believes it's > in a different security context. Even implementing a kexec equivalent > that booted the Windows kernel from Linux wouldn't be terribly difficult > (ReactOS has most of the necessary code already). It's not obvious that > any security is gained at all. There is benefit to keeping malware out of early boot on its own but I also understand that if someone is doing some form of attested boot that a secure bootloader is the cornerstone for the whole system. Obviously we are not implementing Secure Boot to protect the bootloader alone-- like Fedora, we'd like to be bootable on as many systems as possible. I also appreciate your point on not signing the kernel (which is why I said "you are right to point out that Ubuntu's current plan is not enough if someone wants a signed userspace"), but a malware writer will happily move on to the first thing that is unsigned that will achieve a similar result. Virtualization[1] easily comes to mind, but I'm sure there are plenty of other methods. Trying to address these other avenues of attack takes us down the path of a completely locked down system, which is onerous to both users and distribution maintainers. [1]http://lists.fedoraproject.org/pipermail/users/2012-June/419026.html -- 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
