Ubuntu Lays Plans For Getting Past UEFI SecureBoot 393
An anonymous reader writes "Canonical has laid out their plans for handling UEFI SecureBoot on Ubuntu Linux. Similar to Red Hat paying Microsoft to get past UEFI restrictions, Canonical does have a private UEFI key. Beyond that they will also be switching from GRUB to the more liberal efilinux bootloader, and only require bootloader binaries be signed — and they want to setup their own signing infrastructure separate from Microsoft."
How much of the 'operating system' needs to signed (Score:4, Interesting)
Re:UEFI SecureBoot is a catastrophy (Score:3, Interesting)
My 24" Core 2 Duo iMac has EFI Boot. It didn't stop me from installing Linux Mint on it last month (full format & repartition of the hard drive, not as a "guest"). Can someone help me understand what's the difference?
Re:The rootkit would just infect the kernel (Score:2, Interesting)
I'm less familiar with the workings of Linux, but you generally solve that problem in FreeBSD by setting the kernel modules and the various start up files to be immutable and run the system at secure level 1 or higher.
There's probably still ways of infecting or messing with the boot process, but it's a lot harder when you can't change any of the files to load other code.
Signing the kernel, modules and various start up scripts is probably not a bad idea, but you end up with some trouble figuring out where exactly to draw the line.
Kill with fire (Score:4, Interesting)
But no, instead they'll institute this ludicrous dance of keys which will impair the end user's boot experience (which is what UEFI should really be all about) without adding a gram of security (loadable modules at runtime = zero advantage from using "secure" boot).
Re:How much of the 'operating system' needs to sig (Score:2, Interesting)
Absolutely, 100%, this. In doing this, M$ is looking out for its bottom line; it is only tangentially interested in your data security, and then only insofar as it affects said bottom line. The only rootkits "in the wild" that M$ is even remotely concerned about are the ones which circumvent its own activation and policing systems.
Ubuntu Founder knows about signing ... (Score:5, Interesting)
Hi Guys & Gals,
before you all get worked up, please remember that Ubuntu was founded by Mark Shuttleworth. Mark became a billionaire by running Thawte. Thawte is a certificate authority for X.509 certificates.
My take is he knows a thing or two about such infrastructures and I also think he is a positive influence for the free software world.
have a good day!
booting cd's (Score:5, Interesting)
"Booting our CDs will rely on a loader image signed by Microsoft's WinQual key, for much the same reasons as Fedora: it's a key that, realistically, more or less every off-the-shelf system is going to have,...
So that means if my bootcd's that I create or the ones that I have like Hiren's boot cd, bartpe or any other won't work anymore if its not signed by MS ? That means the IT world will get a kick in the balls with this... like Hiren's will pay for the key
Besides, Microsoft made it clear that arm computers which is loaded with windows 8 will make it impossible to disable the UEFI. in other words, no other OS will be possible. Is it me or it's a very bad idea for all of us...except Microsoft which is clear what their intent is with this crap.
No restrictions (Score:2, Interesting)
I work in a lab where we often need to make a custom build machine. There is no way we will accept any kind of UEFI OS restrictions, nor will we pay an extra fee for their removal. If they wish to do business with us and our partners, then we must have the option to install whatever we like.
There shouldn't be any key by default!!! (Score:4, Interesting)
What you have to understand here, is that Ubuntu is only adding yet another layer of vendor lock. It's not better than the one from Microsoft.
The only REAL and TRUE freedom and equality would have been to ask all users to first type a fingerprint before they can use their computer for the first time. Having keys already installed in the BIOS by default is a pure travesty.
And don't tell me that too hard to do for the average user. There's in fact only 2 categories for which it is the case: blind people and those who shouldn't ever touch a computer anyway.
Re:The rootkit would just infect the kernel (Score:5, Interesting)
the bootloader can be configured to load a Linux kernel that chain-loads a compromised Windows kernel
That strikes me as an odd proposition.... The Windows kernel has a lot of requirements out of its bootloader. ...
While that may be true, GRUB has been booting Microsoft Windows for years now. It may have a lot of requirements, but obviously those requirements have been met.
What you might have forgotten is that boot loaders can simply call other boot loaders. It's call chaining, and it is exactly how GRUB boots Micorsoft Windows. You boot to GRUB, which might configure a thing or two (like hide Linux partitions), and then it boots NTLDR (or whatever the latest Microsoft loader is) and the Microsoft boot loader then satisfies all those requirements for the Microsoft Windows operating system.
It's absolutely possible, of course, but the sheer amount of hackery that is required to make it work is just mind boggling... at least to me. Can you link anything that explains your concept?
I won't link, but consider a mail forwarding service. They receive a letter, the might move it internally through a few mail boxes, and then eventually ship it out to you at your new address. What they don't know is that the new address could also be a mail forwarding service. Chaining two mail forwarding services together will still get the mail to the final destination address.
The above example pertains to boot loaders, except that you have the first boot loader set the environment to "boot something" which happens to not be an operating system (actually boot loaders can not differentiate between an OS and a boot loader, because at that level, there are just programs). Without the motherboard configured to only boot signed boot loaders, any number of intermediate boot loaders could be inserted which could then hijack the booting process, perhaps even to the point where they boot a pre-infected (by some means) operating system.
Hopefully this clears things up a bit. I know that boot loaders are only somewhat understood, even by those who use Linux quite a bit. I don't even pretend to be an expert, but it is clear to me that if you want to assure that a certain operating system is booted as it was delivered by the distributor, you need to control the entire boot process from power on to the kernel launch.
Linux's security model protects itself well post-kernel launch, but even Linux could be subverted by sloppy controls over the booting process.
Re:How much of the 'operating system' needs to sig (Score:5, Interesting)
And how long before Microsoft and/or the OEMs start saying you can't do that?
Comment removed (Score:5, Interesting)
*STAGED* boot (Score:4, Interesting)
Also surprised with efilinux. It can load from block devices only, which omits network boot. I understand that grub2 GPL3 concerns make sense, but you would think they might go with elilo. It may be less 'active', but it is capable of doing more than efilinux, notably network deployment.
Canonical specifically stated that EFILinux could be used to a non-signed Grub2 (or maybe they could even sign it through their own infrastrucutre if they can make it GPLv3 compliant). On non-SecureUEFI machine, this is supposed to be the default behaviour they want to do (if EFILinux detects that Secure is disabled, it chains straight to Grub2).
The idea is to load the smallest possible bootloader in signed mode and then do everything else you want from that point onward.
Once EFILinux has chained to Grub2, you can do all the crazy cool stuff you want here.
Just think of EFILinux as a special type of stage1 that is compliant for SecureUEFI devices. (Well technically, the UEFI firmware is the stage1, but you got the idea).