Re: Red Hat Will Pay Microsoft To Get Past UEFI Restrictions
On 06/01/2012 05:34 AM, Sam Varshavchik wrote:
positive and confident that this entire kit-and-kaboodle has no choice but require a closed, hood-welded-shut OS, booted up with a signed chain, in order for it to work.Oracle Solaris?Yes, I think that would qualify.
No it isn't necessary. You're looking at it the wrong way; basically only the things able to boot kernels and kernels themselves have to be signed and trusted to ensure the integrity of the kernels. This is because an untrusted piece of software could execute an otherwise trusted kernel and do bad things behind its back.
For the rest, we trust these kernels to arbitrate our programs and allocate the resources of our machines correctly as they've been doing for decades, with no doubt that they've been compromised themselves thanks to secure boot. Whether the security services offered by the kernels include checking the integrity of all binaries on the machine or not (or the use of many other security features) is irrelevant to secure boot, and only depends on how much security you want your kernel to provide.
We're told that Fedora's bootloader is going to get signed – and by that, that must mean "grub", right?
No, too many updates, it would be unreasonable to get it signed by a third party at each release. The obvious solution would have been to use a certificate store that the firmware could use and get a certificate from a trust broker (here, Microsoft). I'm told this solution didn't make it to the UEFI spec (didn't read it myself), so we're using a technical hack around this: a shim bootloader that will get signed and won't change often (hopefully never). Its sole purpose will be to chainload to the actual bootloader (GRUB2 for example).
Technically this delegates trust just as a certificate would (implicitly this is sort of like a certificate since all packages, including the shim, are signed by Fedora release keys), so the ability for Microsoft to review that shim code has little value. Some people say they won't sign the shims of all the distros (well, those who target average users anyway), I say they get $100 per signature, and duh, it's Micro$oft. They can't review all the components that can execute kernels (all bootloaders and all versions of all kernels) so they have to delegate trust at some point anyway, so might as well make it at the lowest level to make the process smooth.
Plus, if a FOSS kernel or bootloader is used as malware to boot their Windows operating system, it will affect their users, so they do care, and they have to sign as much shims from as many trusted open source distros as possible. The alternative is a big PR and legal storm because users of alternative operating systems won't be able to use their hardware. If we were able to force them to give us a choice of web browsers on their own OS, we will be able to force them to give us a choice of OS on our own machines (we can never own their software, but we own our hardware, so the argument is ten times more powerful this time). They know this, and they already publicly announced they were gonna play ball.
Yet another reason is that if they don't the world will demand more trust brokers more quickly (we should in any case, but people are a little slow when it comes to security). If a business model emerges from this and more companies start to make contracts with OEMs to distribute certificates (signed shims), they will lose control and money. I believe this will and should happen eventually, so they will probably play as nice as possible to keep their customers (they only have a headstart). Remember that they are a lot more of potential customers as we usually think of as desktop users (mobile systems, server systems, custom embedded systems for all kinds of applications and industries). Well, should these potential customers want to boot their systems securely on a wide range of third-party hardware out of the box, that is (and Fedora does).
We really shouldn't see it as Red Hat selling out to Microsoft. As a customer, Red Hat owns Microsoft and will be able to chose another trust broker as soon as other organizations doing this start to appear, should they be dissatisfied with Microsoft's services. Hell, as you state at the end of your post, Red Hat has the infrastructure, the resources, the money and the OEM contacts to provide that service itself for itself and for many other FOSS players. It probably just didn't think about it yet (or not enough, this isn't an easy business, and should be thought through). Note that even Fedora could be able to do it, as many hardware vendors apparently agreed to put Fedora keys in their firmwares. Read the Matthew Garrett's article for the reasons why they didn't want to take the responsibility and ultimately didn't go with that solution.
Now I know that $100 doesn't seem like much to lose from this perspective, and I tend to agree globally. Maybe the prices will go up as some people have predicted, and in a certainly paradoxical way, that would be for the best. The important thing is that trust brokers should value their customers enough that they will want to provide a good service to them. Usually that value comes from money.
And, grub can boot an arbitrary Linux kernel, right? So, a virus that wants to compromise a signed, secure bootload chain, can't it simply install Fedora's signed grub, configured to boot a bare-bones Linux kernel, nothing will prevent that, right?
Fedora's signed shim bootloader will check the integrity of GRUB2. GRUB2 itself will check the integrity of the kernel. So no, it's not that simple, and yes, it works -- it's the one use-case it's been designed for, you'd hope they got it right.
And, Fedora can load any kernel module, right? Hence, load the virus code onto "bare metal", right?
The kernel will check the integrity of the modules.BTW, if you're wondering about loading your own modules or building your own kernel, it wouldn't make sense to ask Fedora to trust your piece of software, since it would have nothing to do with Fedora and won't even be in their repos. So you have to do the logical thing, generate a personal key and sign your own stuff with it. That is if you trust yourself in case you wrote the code (some people shouldn't ;)) or if you trust those who wrote the custom stuff you built/plugged in case you didn't.
If the modules you want are of enough value for all Fedora users, you can ask the kernel maintainers (I guess) to review them, sign them and bundle them in the Fedora repositories. This feels natural.
Then, can't the loaded virus code simply reboot back into the original, Windows bootloader, that's now infected, and simply do what the virus would've done originally, in the absence of a signed bootloader, right? If so, then what the FSCK did having an option for a signed bootloader accomplish, here???
This would only be possible if the infected bootloader is signed by Fedora, since the shim won't load it otherwise. Fedora will review the bootloaders for security breaches (as it does for all its packages as standard QA), so that's not an option.
An alternative would be for the attacker to get its bootloader signed by a trust broker (Microsoft), and thus replace the shim. Hopefully, Microsoft won't just sign anything and review the code, but this is still a real problem IMHO (as I stated already, reviewing shims has little value anyway, the real issue is in delegating trust to good people only).
That and the fact that every hacker in the world will probably make it a fun game of Who's Gonna Get To The Microsoft Root Key First. I'm sure it's locked away Hollywood-style somewhere safe, but Big Corp keys are known to be compromised (especially these last few years).
Note that if they do sign a shim owned by a bad guy, they can blacklist them. As I stated in another thread, $100 might not be enough to prevent them from reacquiring a new signed shim, but that's still better than nothing (difficulty to hide financial traces, necessity to come up with a good story with the trust broker [Microsoft] everytime, etc).
The real solution is to load your own key in the firmware and sign Fedora's shim, hence stating that YOU trust Fedora explicitly (and not because Microsoft trusts it), and remove Microsoft's key, stating that you don't implicitly trust all that Microsoft trusts.
And that's what everybody should and will do. The thing is, you can't do it automatically, obviously, since that would defeat the entire purpose of the system (malware could simply store its own keys). So you, as a user, have to go into the UEFI firmware setup UI when booting your machine, and install your key. I don't know how streamlined the process will be (ask people who have prototypes around), but I suspect many "average" users won't bother / will be afraid to do it. They would be wrong, but forcing people to care about security is known to be fruitless.
IMHO, it should be possible for operating systems to popup a simple dialog asking the user if it trusts the current bootloader, and then automatically generate a key, generate a personal shim (signed with the key) that will verify the integrity of the current bootloader (that the user trusts), install the shim, and then, via the magic of an as of yet non-existent interface, install the key in the firmware securely.
=== SNIP a few ideas for that magic interface ===1. Close to impossible to put in place, no technical restrictions, very easy to use:
It should be technically possible to for example place a special button on the hardware, along with a LED. When the operating system asks to store the key, the LED lights up, and the way the user would approve the move would be to press that button (a bit like how new household routers work to setup Wifi security). Obviously, standardizing on the button and how it is connected to motherboards would be incredibly hard, and that solution would need to be backed up by many big players. Probably not worth all the trouble, but usable for any kind of device (including headless servers, etc).
2. Very hard to put in place, unusable for headless machines, very easy to use (but special care taken to address phishing-like techniques):
Another solution that would be to have UEFI traps so that the firmware itself can grab input and screen to prompt the user for confirmation via a trusted interface with a cool recognizable logo and maybe a crypto QR code or anything that can satisfy the most paranoid users that they're really talking to their firmware and not a phishing program (kind of like what PolicyKit and Microsoft's whateverthatscalled thingie do). I don't know how capable UEFI software is of this, and we're certainly not there yet, but I expect that some community projects will develop alternative open-source UEFI firmwares, who may or may not able to demonstrate if this scheme works, then propose standard interfaces and maybe push hardware vendors to implement them. That kind of thing doesn't happen too often, but it happened in the past.
3. Still hard to implement, but doesn't go all the way to make internal things easier to put in place, unusable for headless machines, a bit less practical to use but still very easy for the average user (same attention to phishing-like techniques however):
A third, more reasonable solution that is still practical would be for the operating system to ask the UEFI firmware to prompt the user on the next reboot, so that she can explicitly state that she trusts the key generated by the operating system. It still needs a new API between the OS and the UEFI firmware, but at least it's only software. The disadvantage is that the user has to reboot, but that's OK, you typically will only renew your keys every few years; I don't think Fedora users in particular still play the uptime games.
4. Actually not too hard to implement, just hard to put in place in the UEFI spec, exact same restrictions and ease of use as idea #3:
To expand on that last solution, a scheme where no direct interface between the OS and the firmware is possible: the firmware could look for a certain file on the disk (there is a special partition for UEFI I believe) at boot. This file can be written by the OS and contain the key and maybe some information about when it was generated, by whom, in what context, and what it was used for (which components were signed) -- essentially, a certificate, signed itself. The firmware can then prompt the user before running the bootloader and display all this information (as well as a fingerprint of the key, of course) so that she can make a safe choice. This solution still requires some changes to the UEFI firmware, but these are I think the less intrusive / most doable.
Note that I didn't give much thought about these ideas yet, they may be fundamentally flawed.
=== / SNIP ===
I don't have any answers to these questions (like I said, I'm feeling a bit stupid today), but I do know one thing for sure. If everything that what's been publicly said on this subject, so far, is true, then: Someone around here is a bloomin' idiot of the first degree. An absolute, total, clueless moron. Complete, and total, brain damage. That could be either myself – a possibility that I am perfectly willing to admit – or Microsoft; or whoever's pushing this.
It's not an easy thing to grasp at first, so don't worry when I say Microsoft isn't being too stupid on this one. Not necessarily nice either (time will tell, but as I said already there's hope), but overall the system works.
The other possibility, of course, is that most of what's been publicly stated about this subject, has either been a complete lie or a fabrication; or certain crucial, fundamental details about this process, have been omitted. It just /cannot/ work the way it's been publicly announced.
I already rambled a bit about the less technical aspects of it here, so I won't go through it again (I should write a blog or something, shouldn't I?), but I hope I cleared things up a bit. I can't say I'm an expert in the matter though, so don't quote me on anything.
Now, let me make a prediction of what I think is /really/ going to happen. After thinking about this, oh, for maybe five minutes, tops, I think I have up with the only answer that makes any logical sense, given everything that's been publicly said. With apologies to Sir Arthur Conan Doyle, whose literary masterpiece I'm about to butcher: when you exclude all possibilities that are logically impossible, whatever's left, no matter how highly improbable or bizarre, must be true. What I'm convinced that this is all about, is that Red Hat will simply get Microsoft to sign a bootloader that will boot a kernel that's signed with Red Hat's private key. The kernel will be configured to load only kernel modules that are also signed by Red Hat's private key. OEMs that supply OEM binary blobs, for stuff like RAID cards, etc, that are certified with RHEL, will get Red Hat to sign their kernel modules for them, also for a token certification key. That's the hood, welded shut, that's absolutely mandatory for a secured bootloader to have any logical purpose, whatsoever.
I believe that's the plan yes. The binary blob issue is still a bit foggy from what I hear, but as you said in other words, there's not much alternatives. Note that as I mentioned already, I really think Red Hat would make a good trust broker between OEMs and community distros. As would the Linux Foundation, the FSF, the OSI, Debian, Canonical, SUSE, and all the other big ones.
Based on publicly known information to me, this is the only situation that makes any sense. Nothing else could possibly work, in any logical fashion. Fedora is not going to be a part of this. In order to boot Fedora, it will be necessary to disable the secure bootload, on the hardware.
I think it would be a shame to pass on that tech, I think it has potential if we do it right, but that's just me. The potential problems with an initial Microsoft monopoly on the signing services will only affect the users who don't care, the rest will install their own keys, and hopefully the whole FOSS community will come up with solutions to streamline the process as well as build a web of trust to help people know who and what to trust and automate as many steps as possible with fancy algorithms and (personal) policies.
I welcome anyone to explain what part of the above is logically false, and why.
Hope that helped, sorry for the length.  http://linux-ima.sourceforge.net/  https://lists.fedoraproject.org/pipermail/users/2012-May/418934.html  http://mjg59.dreamwidth.org/12368.htmlPS Should anyone want to reply to this fat blob, please feel free to branch the thread. I think I've made a big mess.
-- t -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
[Older Fedora Users] [Fedora Announce] [Fedora Package Announce] [EPEL Announce] [Fedora News] [Fedora Cloud] [Fedora Advisory Board] [Fedora Education] [Fedora Security] [Fedora Scitech] [Fedora Robotics] [Fedora Maintainers] [Fedora Infrastructure] [Fedora Websites] [Anaconda Devel] [Fedora Devel Java] [Fedora Legacy] [Fedora Desktop] [Fedora Fonts] [ATA RAID] [Fedora Marketing] [Fedora Management Tools] [Fedora Mentors] [SSH] [Find Someone Special] [Fedora Package Review] [Fedora R Devel] [Fedora PHP Devel] [Kickstart] [Fedora Music] [Fedora Packaging] [Centos] [Fedora SELinux] [Fedora Legal] [Fedora Kernel] [Fedora QA] [Fedora Triage] [Fedora OCaml] [Coolkey] [Virtualization Tools] [ET Management Tools] [Yum Users] [Tux] [Yosemite News] [Yosemite Photos] [Linux Apps] [Maemo Users] [Gnome Users] [KDE Users] [Fedora Tools] [Fedora Art] [Fedora Docs] [Maemo Users] [Asterisk PBX] [Fedora Sparc] [Fedora Universal Network Connector] [Libvirt Users] [Fedora ARM]