Slashdot Mirror
FSF Does Want Secure Boot; They Just Want It Under User Control
Yesterday, we ran a story with the headline "Free Software Foundation Campaigning To Stop UEFI SecureBoot." It's more complicated than that, though, writes gnujoshua: "We want computer manufacturers to implement Secure Boot in a way that is secure. If a user can't disable Secure Boot and they are unable to sign their own software (e.g., bootloader, OS, etc), then we call that particular implementation 'Restricted Boot.' We don't want computer makers to implement Restricted Boot. We want them to implement Secure Boot and to provide a way for individuals to install a fully free OS on their computers. Many computer makers are implementing UEFI Secure Boot in this way, and we want to continue encouraging them to do so." The complete text of the statement they'd like people to sign reads: "We, the undersigned, urge all computer makers implementing UEFI's so-called "Secure Boot" to do it in a way that allows free software operating systems to be installed. To respect user freedom and truly protect user security, manufacturers must either allow computer owners to disable the boot restrictions, or provide a sure-fire way for them to install and run a free software operating system of their choice. We commit that we will neither purchase nor recommend computers that strip users of this critical freedom, and we will actively urge people in our communities to avoid such jailed systems."
What problem does Secure Boot solve, other than Microsoft's "other OS" problem?
I want to delete my account but Slashdot doesn't allow it.
They may say they're committed, but let's hope they put their money where their mouth is the next time a machine they really want comes to market.
The Amarri pray for god, the Caldari pray for profit. the Gallente pray for peace, but the Minmatar pray their ships hol
So then they're fine with the way Windows 8 handles it? Because that's exactly what Microsoft demands of computer manufacturers who want to be certified for Windows 8.
Windows RT is a whole different matter, but Windows RT also accounts for about 0% of the tablet market right now. Why is the FSF making all this noise now, when Apple has been happily locking down the iPad since 2010? Microsoft is just joining the party, and it seems a little late for FSF to get self-righteous about it.
But more power to them I guess. It seems like a tough fight, however, when users have a great deal of choice between tablets (both locked and unlocked), even with the locking down of certain hardware.
'Jailed' is the popular nomenclature. What do you think 'jailbreaking' means on your mobile device? It means unlocking the bootloader so it will boot unsigned or differently signed kernels. Doesnt sound patronizing to me, it sounds descriptive.
Weaslly words? The lockdown in the name of "Secure Boot" is a weasel word. Calling it what it is in its implementation on ARM, "Restricted Boot" is not weasely--it's correct (cf. "Digital Rights Management" vs. "Digital Restrictions Management")
Think about it a moment. The ultimate piece of malware would be one that can make your computer run software of someone else's choice, prevent you from running software other than the malware, and block you from removing the malware from the system or preventing it from running. Every piece of malware out there tries to do this, with varying degrees of success. Look at the malware that tries to disable anti-virus/anti-malware software.
Now, Restricted Boot would give someone else control over what software could boot on the machine, and prevent you from changing that list of authorized software. You cannot authorize software you want to run to run, nor can you remove authorization from software you do not want to run. You can't influence what runs at boot, you can't alter it's operation. In short, you've bought into every malware author's wet dream: a system where they can do anything they want and the user can't do a thing about it.
And if you think "Oh, but all the system software would be signed by Microsoft, so how would the malware authors get the keys to authorize their software?", think about this: Microsoft certificates have already been compromised. The bad guys have already gotten access to what they need to sign software with legitimate Microsoft keys. The certificates used by the Flame malware were only some of the most recent. And I'd note this older bulletin describing a situation where Verisign issued legitimate certificates issued to Microsoft to black-hats with no association with Microsoft. The bad guys obtaining the private keys to sign software isn't a theoretical discussion, it's already actually happened.
So the FSF is basically asking people to sign a petition that asks manufacturers to do what they are already doing and plan on doing ? The current requirements for windows 8 is that users must be able to disable secure boot in the bios and do key management (addition/removal) of keys as well. I don't know of any manufacturer that is planning on doing anything different since that would mean that their systems would not be windows 8 certified.
In fact, I don't think microsoft bans having other keys besides their key in the bios by default.If, for example, the FSF or some coalition (e.g. RedHat, Ubuntu, Debian, etc.) were to come up with some workable way key signing infrastructure, they could petition UEFI/mobo developers to include their keys in shipped products as well. The question is how do you freely allow people to get bootloaders signed without making it easily for malware authors to do the same.
"When you sit with a nice girl for two hours, it seems like two minutes. When you sit on a hot stove for two minutes, it
Why do people think that no one complained about Apple's lock down? They've had a walled garden in place since iOS 2.0 and it's always been a point of contention. Secure Boot just brings the threat of universal lock down that much closer.
Well to be fair both the FSF and EFF have been heavily involved after Apple demonised their customers calling them criminals for for jailbreaking Apples Phones(not theirs). Ignoring the fact that those are *electronic* devices and Apple is nowhere near a monopoly (I now its not a good answer for apple users), but again the same groups are not just focused on Microsoft. As for the FSF a quick Google gives this http://www.defectivebydesign.org/blog/1256, although the jailbreak DMCA exemption for the iPhone...and not the tablet, have been big news on most technology sites.
Most people buying a computer will hear "Secure Boot", and yell, "Good! Secure! War on Terror!"
When they hear "Restricted Boot", they will scream, "Bad! Restricted! War against my freedom!"
It's those folks who this wording is for, not Slashdot folks.
Schroedinger's Brexit: The UK is both in and out of the EU at the same time!
All computers have a SECURE setting. It is called "Power off".
morcego
Being categorically against Secure Boot is akin to be categorically against digital encryption and signing in general just because they are tools that are sometimes used to create DRM. DRM is bad. Secure Boot without user/owner key control can make it worse. The FOSS community should embrace Secure Boot but fight for key control.
Used properly, Secure Boot will make FOSS systems more secure. It is much better to add security measures *before* they are needed rather than after. We have generally been ahead of the curve security-wise for decades. Embracing Secure Boot (with user key control) will help us stay ahead of the curve. If we instead shun Secure Boot there is a very real danger that we will lag behind.
We don't see the world as it is, we see it as we are.
-- Anais Nin
To replace the key and the boot-loader you have to disable "Secure Boot" in the firmware (Disabling by software is not allowed), then update the key (Means flashing a new version of the firmware) and the boot-loader and then reactivate "Secure Boot".
Now think of Average Joe or your grand mother and tell me how someone like them will accomplish this.
Replacing the keys doesn't require reflashing the firmware, you just need go into the UEFI setup screen and add or delete the keys you're interested in. If the key gets compromised, you just go to the setup, add the new key, boot and update the bootloader and go into the setup and remove the old key. Or, even easier, you update the boot-loader on a working system, then go into the UEFI setup and remove the old key and add the new key. The procedure you outlined is unnecessarily complex even assuming that you have to reflash the firmware to get new keys.
"When you sit with a nice girl for two hours, it seems like two minutes. When you sit on a hot stove for two minutes, it
TFS has a headline which says "FSF Does Want Secure Boot". It would appear that this is not the case. The FSF would apparently prefer if secure boot were not implemented at all, but if it must be there, they ask that it be done in a way which allows straightforward user installation of a non-DRM OS.
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
If you don't like the secureboot idea, THEN DON'T BUY PRODUCTS THAT INCLUDE IT. Seriously, not that difficult of a concept to understand.
Direct link to the petition / statement referred to in the summary: http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement/
Only takes a few seconds to sign it!
Just because you haven't seen one doesn't mean they aren't prevalent.
If you(and others here) really want to educate yourself instead of spreading karmawhoring FUD, please read on.
Here are some references about boot malware which UEFI secure boot will prevent.
http://www.chmag.in/article/sep2011/rootkits-are-back-boot-infection [chmag.in]
http://www.theregister.co.uk/2010/11/16/tdl_rootkit_does_64_bit_windows/ [theregister.co.uk]
http://www.computerworld.com/s/article/9217953/Rootkit_infection_requires_Windows_reinstall_says_Microsoft [computerworld.com]
I recommend reading atleast the first link.
Here's one juicy bit:
TDL4 is the most recent high tech and widely spread member of the TDSS family rootkit, targeting x64 operating systems too such as Windows Vista and Windows 7. One of the most striking features of TDL4 is that it is able to load its kernel-mode driver on systems with an enforced kernel-mode code signing policy (64-bit versions of Microsoft Windows Vista and 7) and perform kernel-mode hooks with kernel-mode patch protection policy enabled.
When the driver is loaded into kernel-mode address space it overwrites the MBR (Master Boot Record) of the disk by sending SRB (SCSI Request Block) packets directly to the miniport device object, then it initializes its hidden file system. The bootkit’s modules are written into the hidden file system from the dropper.
The TDL4 bootkit controls two areas of the hard drive one is the MBR and other is the hidden file system created at the time of malware deployment. When any application reads the MBR, the bootkit changes data and returns the contents of the clean MBR i.e. prior to the infection, and also it takes care of Infected MBR by protecting it from overwriting.
The hidden file system with the malicious components also gets protected by the bootkit. So if any application is making an attempt to read sectors of the hard disk where the hidden file system is stored, It will return zeroed buffer instead of the original dataThe bootkit contains code that performs additional checks to prevent the malware from the cleanup. At every start of the system TDL4 bootkit driver gets loaded and initialized properly by performing tasks as follows: Reads the contents of the boot sector, compares it with the infected image stored in hidden file system, if it finds any difference between these two images it rewrites the infected image to the boot sector. Sets the DriverObject field of the miniport device object to point to the bootkit’s driver object and also hooks the DriverStartIo field of the miniport’s driver object. If kernel debugging is enabled then this TDL4 does not install any of it’s components.
TDL4 Rootkit hooks the ATAPI driver i.e. standard windows miniport drivers like atapi.sys. It keeps Device Object at lowest in the device stack, which makes a lot harder to dump TDL4 files.
All these striking features have made TDL4 most notorious Windows rootkit and it is also very important to mention that the key to its success is the boot sector infection.
Another bit:
The original MBR and driver component are stored in encrypted form using the same encryption. Driver component hooks ATAPI's DriverStartIo routine where it monitors for write operations. In case of write operation targeted at the MBR sector, it is changed to read operation. This way it is trying to bypass repair operation by Security Products
The OEMs offered to add Red Hat and Ubuntu etc.'s keys but they refused since they didn't want to have an exclusive solution and neither did they want to be in the position of signing keys. If the Linux foundation stepped up, the OEMs will gladly add their master key to U
This space for rent.