Re: Need more info: UEFI Secure Boot in Fedora [Long]

On 05/31/2012 02:38 PM, Alan Cox wrote: The distributions can review the hypervisor code (then sign it as a symbol of trust) and the kernel can then verify its integrity at runtime (just like the firmware verifies the bootloader's integrity, and the bootloader the kernel's). The hypervisor can then emulate secure boot for the virtual machines and continue the chain. Note that you're already half-way there with KVM, since most of its code runs in the kernel itself. Other hypervisors wouldn't be any different from any other package offered by the distribution, at least if the maintainers provide security support for all of them (as is the case for most serious distros). It would be pointless to sign and verify every binary, library and script on the system if the code isn't trusted. Mature infrastructure for integrity checking already exists: most IDS do file change tracking (they would need to be explicitely supported by the kernel though), but see the Linux Integrity Subsystem (in the form of the Integrity Measurement Architecture and the Extended Verification Module). (Repost: http://mjg59.dreamwidth.org/12368.html?thread=399184#cmt399184) [Reply not directed at anyone in particular, I'm just rambling from now on] Let's just see it from another perspective. The obvious alternative is for Fedora and every other distribution to ask every single hardware vendor to include their own key in their firmwares. It's impossible, plain and simple. The communications channels would have to be super-efficient (they never are with such bureaucracy), the policies extra-clear, and the upgrade processes absolutely smooth (to accommodate with new software distributions, key expiration and thefts). I almost see an entire stack of protocols there, a long standardization process, and we still exclude offline or rarely connected users who won't be able to keep up with slower channels. So, as always in this kind of situation, we add another level of indirection, in the form of a trust broker. Hardware vendors trust a few big brokers in the software industry (more than a dozen would be ideal), and these brokers in turn place their trust in software distributors and make it their job to see that these distributors don't abuse that trust, blacklisting those who do. Not all communities would have the resources to do that (although I think the Linux Foundation should act as a broker). Companies in the software industry can, and they already have the contacts with the OEMs, let them do it. If anything, $100 for such a service with no apparent human verification is probably too low. Many attackers would probably pay-up to have their malware compromise as many machines as possible before they get blacklisted. Infected machines can certainly be stopped from receiving updates, so the revocations will only stop the spreading of the botnets, not shut them down. If they can spare $100 every few months (they probably make way more from their botnet business) to get a new key, they might just be alright. The system may stop the weakest players though. Another big point for making people pay to have their components signed, aside from financing the operation properly (necessary to keep the root key really secure and push the revocations in time) and discouraging small attackers, is that it's increasingly difficult to pay electronically anonymously, at least as long as no broker trusted by the vendors starts issuing signed components for anonymous money (BTC for example). Obviously, and just like the PKI for X509 CA hierarchy, the weakest link of the chain can fail the whole system (which is why there shouldn't be too many brokers, see the current web browsers struggle and last year f*-ups). Now, we only have Microsoft, but hopefully this is only the beginning. Aside from all the obvious potential abuses (blocking free software arbitrarily), the technology is actually quite sound if we can control it. And the good news is, we can. We can and we must. Even though this all looks relatively good(-ish), in reality it's merely good enough (a) for the average user who doesn't care too much about having to trust big corporations to more or less know what they want and to act in their favor and (b) for the average big distribution which doesn't care too much about giving away contact information and a little bit of money. (BTW, if you insist you don't fit that user description yet don't use something like Monkeysphere for your web browsing, then you're a hypocrite.) The good we get out of it is that we can automate every step of the verification process; we all know that security has to be traded for convenience, so here we pay for completely transparent security simply by using a sub-optimal trust model that is still way better than nothing (even though HTTPS w/ X509 PKI is so horribly broken, it still undeniably prevented an extraordinary amount of real attacks). But for the more concerned users (this doesn't only include technical people), good enough doesn't cut it. The bad we get is too inconvenient by itself and so we figure that while we're at it, we might as well trade that inconvenience for actual security, rather than worries and doubts. For now, I think most power-users will generate their own keys and verify each organization by hand (entrusting them via boot loader shims or signing components directly), taking over the role of the big corporations, but with only one easy customer: themselves. In the (far, but not too far) future, I see value for a completely decentralized model for signing components by individuals and small organizations, with fancy algorithms to determine if you should or should not run certain pieces of software, based on what people you trust think about them (with configurable criteria such has "the code must have been reviewed by at least two trustworthy people in the last X weeks). And not just for boot loaders and kernels, but for all software packages, as I already explained. (Untrusted software could automatically be run in a sandbox of some appropriate level, for example with SELinux or LXC.) Well, we're most certainly not there yet, but I really do see potential in that tech. I guess it's up to us, as always; I just hope we're not gonna make the same mistakes as we did with the web again. ... Or maybe everybody's gonna disable it, what do I know anyway ;). -- t