Re: Red Hat Will Pay Microsoft To Get Past UEFI Restrictions
On 06/01/2012 09:46 AM, Alan Cox wrote:
Out of support releases are also an interesting problem. If a hole is found they need to revoke the key. If they do that the users machine is crippled. It's potentially a criminal matter in many EU states as well so whoever issues the revocation could end up in jail. Nobody is really too sure. This is all untested waters.
If we're talking about the kernel, one can always make the boot loader prompt the user whether it wants to continue without the assurance of a safe boot, possibly launching the (unsafe) kernel in some sort of locked down mode (filtering connections and whatnot) to try to avoid compromise in case the system isn't yet infected. All the system has to do is fetch a new kernel and install it somehow, and if it does, even if it *is* infected, it would work, since the bootloader is assumed to be secure.
If it's the bootloader that doesn't match, the shim could do the same.The thing is, if machines are compromised, the first thing the malware will do will be to block the revocations coming from the network. As such, I think that for real-world end-users who don't go fetch revocations frequently via secure back-channels, the only real advantage of secure boot will be to stop the spread of malware, not cure it. For that, you would still need the usual detection and removal techniques.
Don't get me wrong, containing malware infections is still a huge win, especially when we consider the number of active botnets today, but to me I don't think OS developers should worry too much about locking down infected machines. If it's infected, the fight is already lost.
Or I maybe I totally missed something; is the firmware able to go fetch revocations itself? Not sure I'd like that anyway.
Correct - and you need to lock it down way more than that. Also I can't see Red Hat directly signing third party binary blobs. If it does that it implicitly believes they are lawful and also acquires some liability for them in they malfuction.
That's a good point, but a little disclaimer would do, wouldn't it? I mean even today Red Hat shouldn't explicitly support them when it comes to security. I hope they don't.
But you're right, it would seem weird to sign a blob and drop all responsibility for it at the same time. I guess there's no use in secure boot if you execute software you don't trust anyway, so users of third-party binary blobs probably would naturally disable secure boot.
It will be up to the Fedora Board to stop Red Hat corrupting the goals of the Fedora project in this way - or if they won't for people who dislike it to dump Fedora - particularly package maintainers.
That would be, well, extreme. Say if legally OEMs are bound to empower the user to manage the keys in the firmware, would you still advocate against the use of the technology?
I mean, right now there's no real issue, OEMs will most certainly include *at least* the keys for the operating systems they pre-install, and that includes Red Hat (if not then there's something terribly wrong with the OEMs' common sense). With a law that states that you must be able to manage your keys, I believe freedom is untouched. I don't think any hardware vendor stated they would retract that freedom from users.
Now, users who buy machines with Windows pre-installed should expect their firmware to include Microsoft's key, and should be aware that they can add theirs legally. If they don't want to use Windows and don't want the trouble of setting up keys they should either:
(a) Buy from an OEM which builds machines with their OS of choice pre-installed, including a secure boot key for it,
(b) Ask an OEM for a machine without any OS (if you install the OS yourself then you should be responsible for installing the key as well),
(c) Fight an OEM which pre-installs Windows to add a new key, possibly a set of keys from unbiased trust brokers that can distribute certificates (bootloader shims) to your OS of choice to make it more realistic.
Now that seems a little harsh for OEMs, but given Windows little monopoly*, I think everyone is OK with that - there is famously good precedent with users who got their money back on the license for the pre-installed Windows copies they got with their computers (even though their arguably knew that it was explicitly bundled as one product), so I'm pretty sure we'll make it work this time too since the situation is even more extreme.
* We can justify it by stating how hard solutions (a) and (b) actually are, but these kinds of OEMs do exist. They're just too rare.
-- 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]