| |||||||||||||
Garrett: Why UEFI secure boot is difficult for LinuxGarrett: Why UEFI secure boot is difficult for LinuxPosted Jan 18, 2012 17:44 UTC (Wed) by stumbles (guest, #8796)In reply to: Garrett: Why UEFI secure boot is difficult for Linux by Kit Parent article: Garrett: Why UEFI secure boot is difficult for Linux And that is why I say secure boot is nothing but a sham. Booting is not and has never been the problem, its what happens after and secure boot will do zero for that. This is nothing but the proprietary world trying to AOL-ize themselves against anything not proprietary.
(Log in to post comments)
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 18, 2012 17:54 UTC (Wed) by drag (subscriber, #31333) [Link]
> And that is why I say secure boot is nothing but a sham.
It's very much not a sham. As long as you are the one that controls the keys to your own machine then it can be a fantastic thing.
Anytime you deal with securing your OS it's a trade off between usability and security. Keeping that in mind: While it is a PITA to deal with at installation time it is necessary feature if you want to have the possibility of verifying the functioning of your OS.
Now, naturally, Microsoft is doing it for a verity of reasons that go beyond making sure your system is verifiable, but that does not mean that it cannot be a useful tool for Linux users.
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 18, 2012 18:53 UTC (Wed) by stumbles (guest, #8796) [Link] It is not a necessary feature I want because it prevents nothing, secures nothing after boot. The probability or rather the reoccurring nature of someone sneaking into a workplace or your home to install a "rogue virus infected" OS is slim to none. But thanks for trying to get me to drink the Kool-Aid.
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 18, 2012 19:23 UTC (Wed) by drag (subscriber, #31333) [Link]
> It is not a necessary feature I want because it prevents nothing, secures nothing after boot.
If you do not have a secure way to boot your machine then you cannot verify what is running on it after boot unless you are absolutely sure that your machine has never been successfully attacked.
Plain and simple.
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 18, 2012 23:08 UTC (Wed) by stumbles (guest, #8796) [Link] Secure boot would not fix that anyway. All the little nasty viruses, keyloggers and their ilk can hide anywhere within an OS and if not in the OS, then choose your poison (application). Still not convinced this is anything more than a solution looking for a problem. At the very minimum it will be another attack avenue for the proprietary world.
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 19, 2012 9:34 UTC (Thu) by mastro (subscriber, #72665) [Link]
Either the bad guys can run code as root on my machine or they don't.
If they don't, then my boot is already 100% secure because they can't change the boot sector of my disk, the bootloader configuration, the initrd, the kernel or the init scripts.
If they DO have root access, it's because they've found some remote exploit (I keep all my distros up-to-date with security updates, but zero-days are still possible) because I for sure didn't give them a legitimate account on my machine, much less physical access to it.
And if they have found a successful remote exploit, everything I do at boot is pointless, they'll still have full control of my machine. And that INCLUDES the possibility of preventing any security update from being successful while still giving to me the appearance of a completely updated and secure system unless I pay *very* close attention.
There's a reason why a compromised system must never be just *fixed*, it must be rebuilt from a clean install.
Look, the root of the problem is: the boot process must not be modifiable without the consent of the device's owner but must also easy to change for the owner if they want to.
The current boot process does achieve both these goals, UEFI "secure" boot doesn't.
Not even close. Posted Jan 19, 2012 9:57 UTC (Thu) by khim (subscriber, #9252) [Link] And that INCLUDES the possibility of preventing any security update from being successful while still giving to me the appearance of a completely updated and secure system unless I pay *very* close attention. Bullshit. Either you are not looking around you don't undestand how it's done. I've already written about it. You need secure boot and secure kernel update mechanism. That's all. Update mechanism can be much, MUCH, MUCH simpler then the full Linux kernel. You just send update with encrypted new random private key and then (when remote system acknoleged update and supposedly installed it) ask to sign a challenge with this new private key. If there are no response or if response is wrong then you know system was hosed and should be disconnected. There's a reason why a compromised system must never be just *fixed*, it must be rebuilt from a clean install. Right. But with secure boot you can keep you "clear install" on the same physical media as the rest of the system :-) Look, the root of the problem is: the boot process must not be modifiable without the consent of the device's owner but must also easy to change for the owner if they want to. Of course it does! You don't own Windows or iOS. You rent it. The real owner is Microsoft, Apple, etc. And UEFI boot absolutely does provide the required capability for the real owner (see above). The real owners were long concerned by the fact that mere lessee can change the system without their consent. UEFI is solution for this problem. After public outcry they decided to allow this capability for some time on x86, but ARM is a new platform and it'll be created properly from the start: real owner will have the ability to rebuild the system while mere tenant will not. What's your problem?
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 18, 2012 21:30 UTC (Wed) by elanthis (guest, #6227) [Link]
You are missing a serious part of the picture here. SecureBoot by itself just secures the OS kernel. An OS supporting SecureBoot is expected to use the Trusted Computing modules to protect runtime services and Administrator-level processes. The end result is that even if you get a virus somehow that gets into the kernel, you can just reboot into Safe Mode and clean it out safely. Without Secure Boot, you can't trust any of the other security measures to still be effective, so the only recourse after a compromise is to wipe everything and reinstall from scratch on new hardware with clean firmware. Which can range from "annoying" to "prohibitively f**king time consuming and expensive."
All security is just risk management. Nothing makes you 100% safe, but you can take steps to make yourself safer than you were before. By your logic, we might as well remove security levels, passwords, sandboxes, and firewalls, since none of those actually stop a dedicated hacker from getting into your systems. Obviously you don't believe that because you know that they add some value and reduce risks. SecureBoot is just another small step that reduces those risks a little bit more.
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 18, 2012 23:11 UTC (Wed) by stumbles (guest, #8796) [Link] Or boot off a live CD and go about your business.
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 19, 2012 7:39 UTC (Thu) by ekj (guest, #1524) [Link]
That *is* a form of secure boot: It works if you're absolutely certain that the code that starts the computer, reads in the boot-block on the CD-ROM and executes it, does so in a secure manner and could not be subverted.
If there's a possibility that this code is subverted, all bets are off.
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 19, 2012 13:53 UTC (Thu) by drag (subscriber, #31333) [Link]
Also if your boot loader checks the signature on the kernel and the initrd then you can use the initrd to verify the rest of your system using file-based IDS.
This had the advantage over a live cd system in that it's automatable and is easier for the OS vendor to support.
|
|||||||||||||