Ubuntu Can't Trust FSF's Secure Boot Solution 377
sfcrazy writes "The Free Software Foundation recently published a whitepaper criticizing Ubuntu's move to drop Grub 2 in order to support Microsoft's UEFI Secure Boot. The FSF also recommended that Ubuntu should reconsider their decision. Ubuntu's charismatic chief, Mark Shuttleworth, has responded to the situation during an interview, and explained the reason they won't change their stand on dropping Grub 2 from Ubuntu. Shuttleworth said, 'The SFLC advice to us was that the FSF could require key disclosure if some OEM screwed up. As nice as it is that someone at the FSF says they would not, we have to plan for a world where leaders change and institutional priorities change. The FSF wrote a licence that would give them the rights to take specific actions, and it's hard for them to argue they never would!'"
Mandatory Warning. (Score:5, Informative)
Serious Sandwich, aka Bonch, Sharklaser, Tech* etc is one of a number of sockpuppet accounts established and maintained by Burson Marsteller on behalf of Microsoft.
Their presence in this discussion means comments and moderation will be slanted to emphasize their client's viewpoint.
Treat all commenters in this discussion with suspicion and derision. Do not post or reply to posts yourself.
Re:Ubuntu understands users (Score:3, Informative)
It's also optional
Unless you're on ARM, in which case it won't be, so no, it's not always optional.
Shuttleworth isn't being entirely candid (Score:5, Informative)
I'm sure the SFLC did tell him that a mistake by an OEM could force disclosure of the signing key. But notice he doesn't say explicitly that they told him it could force disclosure of Canonical's signing key. That's because I'm pretty sure they didn't tell him that. Think about it. The logic here is that an action that breaches the GPLv3 by a downstream distributor (the OEM) could force the upstream to correct the breach. Now, suppose I put that in the context of code: I distribute a GPLv3'd piece of software, you receive it from me, modify it and distribute the modified version. If Shuttleworth's argument is correct, then I am in breach of the GPLv3 because I'm not distributing the source code to your modifications as required by the GPLv3. But that's obvious nonsense, since I'm only required to distribute the source code to the software I'm distributing and I'm not distributing your modifications at all. Only you're doing that, and the only way you can pass your obligations back to me is if you're me in the legal sense (ie. a wholly-owned subsidiary company or a division of my company) or if I've signed a contract with you to take on those obligations for you.
So I suspect that while Canonical would be required to distribute any tools needed to create signed bootloaders and the keys needed for the BIOS to boot them, unless they're distributing the actual hardware it'd be on the OEM (who selected the hardware) to take any steps necessary to comply with the GPLv3 as regards the hardware (ie. either choose a BIOS that allowed keys to be enrolled or Secure Boot to be disabled, or distribute their own signing keys). Of course that could place the OEMs in a bind: if they used Canonical's signed binaries and keys then the OEM would be obliged to provide the signing key, but Canonical is not obliged to provide it to them. Which I think is exactly the situation the FSF desires: OEMs placed in a position where to use a very desirable bit of software in their equipment requires selecting a BIOS that permits user control over the Secure Boot process and keys.
Re:Mandatory Warning. (Score:4, Informative)
Well, whoever he is he's factually wrong.
UEFI booting has absolutely nothing to do with boot sectors. Secure boot is part of (A superset of?) UEFI booting. A system doing a UEFI neither needs, looks for, nor cares about the boot sector.
Boot sectors are part of the old, old, old legacy boot method where you had to chain larger and larger bits of code to jump the CPU in to its newer, more powerful modes. More or less, the sytem starts in a mode so dumb it can only run a few bytes of code. It can't read or interperate filesystems. It cant jump in to a modern 32 or 64bit kernel I can't do anything but read very simple code from a fixed location. This location is the boot sector, and it's always sector 0. This code calls a larger boot loader, then a larger one, then eventually reaches a point where it can start up a modern operating system.
UEFI is actually a tiny OS that can read partitions/filesystems directly and can call a modern UEFI compatable boot loader directly. Now, not to say you can't subvert your modern UEFI bootloader. (Thats what secure boot is all about) But it certianly has nothing to do with boot sectors.
Re:Ubuntu understands users (Score:1, Informative)
The security only runs one way. Once somebody can subvert the boot process in any way (and show me ONE device that hasn't been rooted) all malware need do is what it has always been doing. Take over the boot.
That is correct. Which is why the UEFI/BIOS needs to be able to be secure. It does this in a number of ways, one of which is secure boot, which verifies the executable that it passes control to after initialization is one that has been untampered with. This prevents any malware from trying to infect the system that can get control before the OS itself does.
Then IT checks the sig on Windows and tells it that "I'm the bootloader, you can trust me." and there isn't a 100% sure way to verify backwards.
You have the process backwards. UEFI/BIOS doesn't tell the bootloader that it can trust the UEFI/BIOS. The UEFI/BIOS checks and verifies the boot loader to make sure it's untampered with before handing off control to it. The trust the other way is implied/assumed.
We all know most vendors will still be flashing the BIOS/UEFI from Windows because anything else will be too much hassle for the end users.
It's pretty easy for UEFI makers to include the process to update itself within itself. If you don't have the know how to boot to your UEFI menu, then you really shouldn't be updating your UEFI/BIOS anyway. Really, it's not that difficult. Most are graphical, and pretty simple.
They will pretty much have to do it to get key revocation lists. Oh yea they talk now about secure pathways through secured supervisor modes but we know that if it is running Windows nothing on that CPU is really and truly secure.
I'm not sure why they would need a revocation list. There is a handful of keys and they won't ever be revoked. You can add keys (or remove them I suppose), but the list of signatures of untampered boot loaders shouldn't need to ever be revoked. Even in the case that such a process does need to be put into place, that would either have to be done through the UEFI/BIOS subsystem itself, or verified by the UEFI/BIOS system before commiting it.
And wait until the motherboard makers start encheapening the system. Remember when a physical write protect jumper was standard to protect flash BIOS? And a ROM portion with an emergency rescue reflash util? When was the last time you saw any of those protective measures on sonsumer equipment?
And you get what you pay for sometimes. Nothing stopping $.02 manufacturers from shipping UEFI/BIOSes preinfected either. Just because a solution doesn't solve the entire worlds problems shouldn't mean you don't implement it. This is a solution to one problem that simply put, can't be solved any other way. It's a good solution, but it doesn't turn smog infested, violence prone, poor cities into gleaming bastions of godlyness either.
Re:Ubuntu understands users (Score:2, Informative)
> Restricted boot environments are about DRM, not about securing the system from malware
Really? Here are some references about boot malware which UEFI secure boot can 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]
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 data.
The 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. ....
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.
Atleast you'd have some credibility left if you had said that the restrictions could be about DRM also.
I do not want to choose between Fedora and Ubuntu; I want to use whatever distro I fancy, and I want to be able to switch distros without jumping through hoops (yes, there are hoops to jump through now; this move by Canonical does nothing to advance any solution to that problem).
Moving one slid
Re:Good riddance (Score:3, Informative)
The big advantage of GRUB over LILO was that you didn't have to worry about an unbootable machine if you changed anything and forgot to 'rerun lilo'.
Which was never a big deal anyway. Just boot from external media run lilo, and reboot. Worked every single time. Why is that worth writing a whole new boot loader over?
Grub on the other hand would occasionally hose itself for no reason. Booting from external media and running 'grub-install' or 'update-grub' usually worked, but I still had one system that grub so totally screwed up that even that wasn't enough.
Re:Not quite: They want to still work in a screwup (Score:2, Informative)
The Linux kernel is GPL v2 because many, many contributions were made without the "or later" clause. Regardless of any desire to, it is legally impossible to transition to v3 without a massive auditing effort to locate and rewrite every contribution made without the "or later" clause or to locate the original authors and secure permission.
A little background on Burson-Marsteller (Score:5, Informative)
(please note that I am NOT the same AC that made the accusation, but rather, one that wondered who this firm is, so I figured I would share my findings...)
Ok, so I do a bit of digging for two minutes, and came up with this:
Who:
Burson-Marsteller is a PR firm. As in, a really, really, REALLY big fuckin' firm. Apparently the only place on Earth worth mentioning that doesn't have an office of theirs is Antarctica.
http://en.wikipedia.org/wiki/Burson-Marsteller
Where:
Burson-Marsteller has been very, very busy. I haven't had time to second-source the entries from Wikipedia, but supposedly this firm has been at the forefront of a lot of really, really bad shit. The original Tylenol Poisoning scare, Three Mile Island, PR for Phillip Morris; you name the PR nightmare, and there's a good chance they've been there to mop up. In other words, these guys are "World-Class Spin Doctors".
When:
"When" really doesn't even apply in the context I'm using because they are still in business as part of the WPP plc, the world's largest advertising agency. Which means, "when" is really all the time.
http://en.wikipedia.org/wiki/WPP_Group
What:
It took a bit of digging but I found a set of links that tied them back to Microsoft. Ok, so now we have something tying the two together with Microsoft as Burson-Marsteller's client.
http://www.economist.com/blogs/babbage/2012/03/microsoft-v-google
http://www.techdirt.com/articles/20110513/15424314269/burson-marsteller-digs-itself-deeper-hole-deletes-critical-comments-its-facebook-page.shtml
The accusation:
I myself have observed "shill-like" behavior over the last decade on Slashdot, and in the last 4 years it has intensified quite a bit. I believe that, while there is no direct way to prove the accusation, there is sufficient background for readers to make an informed decision as to the possibility of the accusation being accurate.
Why AC:
Yes, I have an account here, let's just say numbered under 200,000 and leave it at that. No, I will not post this with my account for reasons that should be readily apparent to anyone with two brain cells attached - which is to say, attracting the attention of a world-sized firm to my little pittance is probably not the wisest move to make. If they have enough money to pay people to sit around all day and troll slashdot forums, then they certainly have enough money to harass me (given the opportunity).
Sometimes the best tactic to keep out of harm, is to simply not be seen.
Re:Not quite: They want to still work in a screwup (Score:4, Informative)
You don't understand GPL.
GPL is there to allow the final user to do whatever he want with his hardware.
A developer is not the final users, if he wants to use GPL code, he must give the same rights he received to everyone.
GPL2 had some holes that allowed some developers/builders to take the work of others and not giving back what they should.
GPL3 was made to fix that holes... yep, some people that were abusing the GPLv2 holes didnt like it, but bad luck, its not their code.
If you don't like that license, don't use programs with it and start over with your preferred license. you are not important, the final users are!
So here is the global view:
GPL is to give ALL power to the final users
Closed source gives all the power to the product owners/builders... the user loses freedom
BSD/MIT gives all the power to the developer and hope that product owners/builders are nice to not take the user freedom...
<sarcasm>everyone knows that companies are always nice to the users!!</sarcasm>
Re:I Call Bullshit. (Score:5, Informative)
I think the reason for the SFLC's advice regarding having to reveal th key is that Canonical distributes updates directly. Here's the scenario:
1. The OEM sells a PC with Ubuntu preloaded and the BIOS locked.
2. The user buys the PC and then updates GRUB2 to a newer version supplied from the Ubuntu repositories. It'll install fine, because it's been signed by Canonical, and the Canonical key is in the BIOS.
3. User wants to modify GRUB2. They get the sources from Canonical, modify, recompile, and try to install. The computer won't boot, because their modified version is missing a signature.
This means that Canonical is violating the Tivoisation clause in the GPLv3. Canonical is redistributing GRUB2 to the user, and the licence won't let them do that unless they also provide the user with everything they need to be able to change GRUB2 and load it onto their computer just as they're doing with the original they were given. Since Canonical can't unlock the BIOS (only the OEM can), the only way they can fulfil those requirements is by giving out their key.