On Mon, Jun 25, 2012 at 05:35:34PM -0500, Jamie Strandboge wrote: > 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).
Or demonstrate that a binary is being actively used to attack systems. > There is benefit to keeping malware out of early boot on its own I'm not convinced that's true. Anything launched by the bootloader has the same level of access to the hardware as the bootloader. What protection does locking down the bootloader give you over not locking anything down? > 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. Your design decision makes it impossible for anyone signed with the Microsoft key to implement any kind of security beyond the bootloader. This is somewhat incompatible with our plans, and also incompatible with Microsoft's statements about secure boot being something that extends from the bootloader up to the kernel and drivers. I don't deny that it's a rational choice given your security goals, but it has an impact on the designs envisaged by everyone else working on the problem. -- 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
