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). > 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. There's no requirement that dbx updates be simultaneous with kernel updates, and that's actually something you wouldn't want in most cases - you want a grace period in order to avoid any accidental blacklisting before updates with a new key have appeared. > 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. -- Matthew Garrett | mj...@srcf.ucam.org -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
