On Mon, 25 Jun 2012, Seth Johnson <seth.p.johnson@xxxxxxxxx> wrote:
> On Mon, Jun 25, 2012 at 2:48 PM, Gregory Maxwell <gmaxwell@xxxxxxxxx> wrote: > On Mon, Jun 25, 2012 at 2:37 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: >> I'm reading they're going to use a modified Intel efilinux, not writing a new boot loader. And that they will not require either signed kernel or kernel modules. > > Thats my understanding. > >> So what's the point of Secure Pre-Boot? > > Making Ubuntu work on the hardware people have. Which is the > justification given here why Fedora needed to adopt crytographic > signing of the kernel/drivers/etc. > > I think this all would have been a much simpler matter if it wasn't > being described as essential for keeping Fedora operable on the > computers of the common folk. > > Of course, users who want more aggressive secureboot would be free to > replace the keys in their system with ones which only sign bootloaders > which are more thoroughly locked down… but I don't see evidence of > the demand. (can you point to some?) It would appear that right now, it's a matter of a political necessity, unforeseen by the general population, though vaguely bugging the free software development community. I would agree there's not much demonstrated demand, but if we wait til the worst apprehensions come true, we will be at a disadvantage. The general population does not experience the problem that free software developers can more readily anticipate. >> I think for at least 9 months now the idea of a strictly pre-boot implementation of Secure Boot is possible, but meaningless to the point of "WTF, why bother?" with the effort required. It's like building a bridge that's 80% complete, and therefore 100% useless. > > And the kernel hands off control to a init/systemd which is unsigned— > which can be rooted and exploit a vulnerable kernel to prevent > updates. It's like building a bridge that is _10%_ complete, and > therefore 100% useless. :) > > … the amount of critical userspace code that runs before updates can > be processed is enormous and the kernel and bootloader is just a tiny > fraction of that. Why not build the 100% bridge that actually > provides a remotely secured platform? Because it's incompatible with > software freedom. I don't see this. If you choose an authority and can put their keys into your own box, then you're good until that authority is compromised. This, if I am tracking this correctly, is the infrastructure part of the solution. You just have to get out in front with the trusted authority. I would think that if FSF provided keys, that would be pretty trustworthy, though for the following reason I actually don't think they should be out front with this part, because they would clearly be targetted, and we wouldn't want that to happen until there was a developed market in trust authorities. It would not, of course, assure that all "content" and code could be processed freely, but it would create the context in which we could demonstrate that the authorities that provide palladiated "content" and code are restricting people's capacity to compute. Keep up providing authorities that assure software freedom -- do the whack a mole bit if necessary -- and that context will be the context that demonstrates to the people at large that there are people out there that have truly fully-functional computers and they want to have that too. This is not inconsistent with software freedom. You're going to have a root key. If it's your own, you can't do much unless you buy into the englobulators' signing regime; if you want to do more, you have to create some sort of collaborative context that uses a common trusted key. We might have lots of little groups like that, but they will not be able to stand up against the political norms we can easily anticipate being established if we do not come to terms with how to make software freedom viable while using Secure Boot our own selves. So to me that clearly indicates a *political* need for developers who want to keep their freedom, to get out in front and *create* a market in trusted authorities. If your idea of software freedom is decentralized in some sort of resolutely individualistic way, you'll be locked out by the larger forces. That's why it's necessary to get out in front ad establish the infrastructure, and get people offering lots of trust authorities, start trying to conceptualize that market and how and whether it would be competitive. This is the way I see the situation; I feel that I step a bit beyond my expertise or comprehension as I describe it, so somebody please tell me if my conception misses anything. I defer to Jay usually for this very reason. So have at it: let me know what you see when you see me explain this piece of the puzzle. :-) Seth
I will not address directly any particular point in this branch of the thread, but I have some questions about what sort of capabilities the UEFI will have in machines sold later this year: 1. What is the mechanism for remote revocation of signing keys? 2. In particular, will the UEFI be able to revoke, at the command of Hardware Key Central, signing keys without a standard (style of) kernel being booted? That is, can the UEFI receive commands over the Net using its own network capabilities? 3. If booting a standard style of kernel is required to revoke, at the command of Hardware Key Central, signing keys, then the standard kernel must be capable of receiving and interpreting such commands, and also be capable of modifying the memory of the UEFI hardware. How will the Englobulators ensure that every signed-by-Microsoft Red Hat kernel will take orders from Hardware Key Central? Note I assume here that Hardware Key Central is controlled by the Englobulators. These questions are asked so that I may better lay out some actual security considerations in a later post. I thank you Fedora UEFI team for reading this! oo--JS.
> Central control is Microsoft's strength, not > Fedora's.
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
