Weekly Edition
Return to the Announcements page
| |||||||||||||
Garrett: Why UEFI secure boot is difficult for Linux
On his blog, Matthew Garrett provides an update on the UEFI secure boot situation. Unlike what some have said, the Microsoft certification requirements for Windows 8 still place significant barriers in the way of installing Linux—even on x86 systems—which Garrett outlines. "I wrote about the technical details of supporting the UEFI secure boot specification with Linux. Despite me pretty clearly saying that this was ignoring issues of licensing and key distribution and the like, people are now using it to claim that Linux could support secure boot with minimal effort. In a sense, they're right. The technical implementation details are fairly straightforward. But they're not the difficult bit."
(Log in to post comments)
Most points are valid... Posted Jan 18, 2012 13:47 UTC (Wed) by khim (subscriber, #9252) [Link] But this is pure FUD: Any description of the UI. It's effectively impossible to document Linux installation when the first step becomes (a) complicated and (b) vendor specific. Sorry, but this was the case for ages. To install Linux (or Windows, for that matter) you must boot from floppy or CD/DVD/UMS. Long time ago computers tried floppy first then continued with HDD. Boot viruses exploited this capability quite efficiently and since then the very first step in the process of installation of any OS is (a) complicated and (b) vendor specific. Singed boot does not change anything materially in this regard.
Most points are valid... Posted Jan 18, 2012 13:57 UTC (Wed) by stumbles (guest, #8796) [Link] Secure boot is a sham no matter which way its looked at.
Most points are valid... Posted Jan 18, 2012 17:14 UTC (Wed) by wdaniels (guest, #80192) [Link]
Agreed. When was the last time you actually found malware that was running from the bootloader? I know it can and does happen on occasion, but I've not actually seen it since the days of floppy disks and I doubt anyone I know has either.
Usually when we hear about these things it is some secret service or police force, and I don't expect those organisations will have much trouble signing whatever code they like.
And what about virtualisation? Are we going to see VM BIOS with secure boot? If we do I should think it will be changed to allow remote administration of keys for unattended installs etc. Just one more reason to head for virtualised infrastructure.
This whole UEFI thing is a complete waste of time. But hopefully it will encourage dedicated Linux hardware retailers...ultimately that's how the non-techies prefer to shop anyway.
Open source BIOS not looking so silly now! :D
Most points are valid... Posted Jan 18, 2012 17:57 UTC (Wed) by wmf (guest, #33791) [Link]
AFAIK there's a bootloader that bypasses Windows activation. Whether that's malware depends on whether you're Microsoft or not.
Most points are valid... Posted Jan 18, 2012 20:28 UTC (Wed) by Fowl (subscriber, #65667) [Link] Well Microsoft's anti-malware suite doesn't think so, at least. Surprisingly quite a few other vendors do though.
Most points are valid... Posted Jan 20, 2012 3:35 UTC (Fri) by hitmark (guest, #34609) [Link]
I seem to recall reading about a botnet of some kind that employed bootloader infection as a way to spread.
Most points are valid... Posted Jan 18, 2012 14:00 UTC (Wed) by cortana (subscriber, #24596) [Link]
Secure Boot makes the situation worse though--the user still has to select a boot medium, but now also has to find a way to disable SB...
Actually things were just improving beyond that point. (WUBI) Posted Jan 18, 2012 15:34 UTC (Wed) by werth1 (subscriber, #48435) [Link]
Actually you don't need to fiddle with boot disks and iso images.
There are easier ways: http://www.ubuntu.com/download/ubuntu/windows-installer
So this is not "pure FUD"
Most points are valid... Posted Jan 18, 2012 16:03 UTC (Wed) by ayers (subscriber, #53541) [Link]
Back then the folks who installed GNU/Linux where already computer literate. Today the user spectrum is much wider. Very few of those ordinary users will consider removing or replacing "security" keys just to install an alternate OS.
Today they can be running Windows and install a GNU/Linux distribution as if it were yet another application. I'm not sure whether UEFI would disallow the installation but AFAIU it will definitely not allow the execution of an alternate boot loader and even if the installation where able to reconfigure the existing boot loader, it would still not boot the kernel unless it has been signed by an existing authority.
Even if Red-Hat, Canonical and SuSE were able to have their bootloaders and kernels signed by some authority, even if SPI manages to get Debian signed, even if the FSF manages to get gNewSense signed, there are so many other valid distributions out there that you would probably end up with many signing authorities who all would need there keys supported by all vendors that we'd most likely end up in same mess that we have with SSL.
Currently we have hundreds of authorities in our browsers including very dubious ones. Hardly anyone currently is able to manage them, even technical inclined. Do you expect ordinary users to be able to manage the keys even if they were to have the tools?
The hurdle is, by far, way to high. This will dampen the spread of all free operating systems considerably.
Most points are valid... Posted Jan 18, 2012 17:05 UTC (Wed) by NAR (subscriber, #1313) [Link]
The user spectrum may be wider, but those who're installing Linux for them are still the computer literate family members or friends: I mean I know a lot of people who can use a computer (send e-mails, update facebook pages, etc.), but don't have a clue about what BIOS is. On the other hand the computer literate family members or friends might not want to mess with the keys...
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 18, 2012 17:00 UTC (Wed) by Mellobob (guest, #82390) [Link]
I'm not an expert in security. At all. But, why is so much being done at the boot end of this? After all, most people effected by computer in-security are windows users who probably never do anything at a boot level. Get get zapped by malware and viruses which are installed much later than boot.
I may be wrong (again) but I suspect that this has nothing to do with security ... except the security of forcing people to commit to a certain OS.
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 18, 2012 17:13 UTC (Wed) by drag (subscriber, #31333) [Link]
Because the only way to validate the software installed on a computer is by starting at the boot or having a completely separate OS/Machine for validating your software.
Imagine a attacker is able to violate the security of your system. They install what is known as a 'Kernel Level Root Kit'. This software modifies how your kernel behaves in order to hide the fact that your system has been compromised.
This makes any sort of 'root kit scanner' or 'virus scanner' completely worthless. They depend on the kernel syscalls, proc, and such things to provide a accurate picture of what is going on in your machine. Since your system's kernel is now, effectively, the malware your fighting against it is impossible to know if your machine is secure or not.
Previous to 'trusted computing' or 'secure boot' initiatives the only way to validate your installation would be to boot up in a live cdrom or seperate machine or something like that so you could build a checksum of files on your system and compare against a known good list. Needless to say that this is very error prone, difficult, and expensive process.
Any suggestions about running 'rootkitkiller' scripts or trying to use rpm's checksum database to validate your system is just utterly naive at best and downright deceptive and self-defeating generally. Just really useless.
Kernel level root kits have been around in Linux/Unix-land for decades. Now that most Window users are sophisticated enough to run anti-malware and anti-virus in a sophisticated manner they are VERY common. I, personally, have seen several Windows machines with kernel level root kits.
With secure boot loader + signed kernel + signed drivers then theoretically all you have to do to guard against this is to reboot.
Providing your software is not vulnerable to a attack during boot-up it should provide a very effective way to know for certain what is running on your system.
This is currently not possible on Linux unless you go through extraordinary steps.
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 18, 2012 19:27 UTC (Wed) by marm (guest, #53705) [Link]
As long as you have a security hole in the system, which allows anybody to get superuser rights, it matters very little if you are able to secure the boot process or not. If you do, any malware can still gain root privileges just after bootup and hide itself from all security scans.
A real remedy to most common security problems would be locking down applications, not the kernel.
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 18, 2012 20:31 UTC (Wed) by drag (subscriber, #31333) [Link]
>As long as you have a security hole in the system, which allows anybody to get superuser rights, it matters very little if you are able to secure the boot process or not. If you do, any malware can still gain root privileges just after bootup and hide itself from all security scans.
Sorta.
IF the hole allows the attacking software to subvert the kernel very close to boot up (say before your anti-virus starts) then a secure boot is not going to help you.
This potential for 'runtime hole' is the significant flaw to the system.
But it still provides you a advantage over the malware in that you can do things like update your kernel to a newer version and still be able to trust it. So if you find out that you have a security hole in your kernel and manage to patch it then you get a good chance of defeating the malware. Especially if your kernel has some anti-malware features built into it.
> A real remedy to most common security problems would be locking down applications, not the kernel.
Yes, ideally, you will want to only run perfectly secure applications with perfectly secure configurations and be a perfectly competent administrator.. but we know that is not going to be possible.
So this means that you still have a problem of detecting compromised systems when they occur. Right now Linux does not a effective solution. Having a 'secure chain of trust' at boot up is not a total solution in itself, but I think it's a necessary component.
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 18, 2012 23:04 UTC (Wed) by marm (guest, #53705) [Link]
When I want to detect a compromised system, I can easily boot a different system from a safe media. This is easy and much more reliable than relying on secure boot features.
> Yes, ideally, you will want to only run perfectly secure applications with perfectly secure configurations and be a perfectly competent administrator.. but we know that is not going to be possible.
Still, even insecure applications can be sandboxed by the system, so that the harm they can incur is very limited.
As long as remote malware is easily able to delete all my files or upload them on RapidShare due to buggy applications, I do not really care if the rest of the OS is compromised.
This is not really true, of course... Posted Jan 18, 2012 20:38 UTC (Wed) by khim (subscriber, #9252) [Link] As long as you have a security hole in the system, which allows anybody to get superuser rights, it matters very little if you are able to secure the boot process or not. You assume hole can not be patched - why? If you do, any malware can still gain root privileges just after bootup and hide itself from all security scans. Not really. It's easy to create secure update process which just checks the signature and then applies update to your OS. Since it'll do just an update and will include tiny amount of code it can be made pretty bullet-proof. This is not theory - it was checked on practice. PS3 had extensive multiplayer protection, but eventually (after many years) it was broken. And for a relatively brief time (half-year or so) you had the ability to crack PS3 open using hardware token. Almost everything was compromised: hypervisor, loader, etc. Just one thing survived: secure boot and update system. Now, year after release of 3.56 firmware various cracker sites still contain the same messages in large red letters: For those on v3.56 or v3.60 or v3.61 or v3.66 or v.400- NO Downgrade, NO Jailbreak and NO CFW!. Sure, the fact that SONY used secure boot to protect PS3 from it's owner is despicable, but the story proves capabilities of secure boot quite nicely.
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 18, 2012 17:18 UTC (Wed) by Kit (guest, #55925) [Link] It's not about when your computer gets infected, but about how deeply the infection can wiggle itself into your system.I'm not sure how far the signing of 'secure boot' is supposed to go, but it will at least ensure some components you're loading from disk are trustworthy at the time. The virus could still implant itself as the first component of the boot process that isn't signed, but at least that would make it a bit harder, and slightly lower the places it could potentially be hiding (not by a large amount, obviously). It certainly isn't perfect, and it certainly won't make your system magically "secure", but it is a step in the right direction. Of course, just like as said in the comments to the "NSA releases security-enhanced Android" right before this article, it could be used as a weapon against the user as well. Microsoft might be motivated in part by limiting the growth of Linux... although, I honestly doubt that they're really all that worried about Linux on the desktop. Limiting Android is a more reasonable claim, but, even that doesn't seem likely, as manufacturers will likely be releasing variants of the same model running Android. Google should have no issues signing Android, nor should the manufacturers themselves. The question, in this case, would be how hard would it be for CyanogenMod and other independent groups to get their keys added.
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 18, 2012 17:44 UTC (Wed) by stumbles (guest, #8796) [Link] 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.
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.
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 18, 2012 17:50 UTC (Wed) by drag (subscriber, #31333) [Link]
They won't get their keys added.
What you'll have to do is take advantage of "custom mode" to allow a user/installer to use their own keys. This mode is described in the kernel.
As far as 'boot loader' malware, it's not rare to install data into the MBR to make it easier for your virus (or whatever) to re-infect a machine.
The latest Windows malware I have had the misfortune to run into latched itself into the NT kernel's block driver stack at the lowest level. It had the capability of creating new subvolumes on the root file system and installing itself to that. This little trick meant that even formatting the file system and re-installing Windows wasn't enough to get rid of it permanently (although it was not clear if it could somehow re-install itself in a new installation. It doubt that would be possible unless it hooked into the MBR or something like that).
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 18, 2012 17:57 UTC (Wed) by drag (subscriber, #31333) [Link]
> This mode is described in the kernel.
uck. I meant "This mode is described in the article".
Antitrust Posted Jan 18, 2012 18:27 UTC (Wed) by TheGopher (subscriber, #59256) [Link]
I think the best idea is to start contacting relevant antitrust authorities.
Here is a link to the european comissions page for reporting competition abuses:
About the install procedure Posted Jan 18, 2012 18:49 UTC (Wed) by jthill (guest, #56558) [Link] The box will come pre-set to maintain/install Windows with a key that matches everything delivered from Microsoft and anybody Microsoft(?) likes. Anything but "use Windows" will require disabling secure boot or an even more intimidating key installation. As I see it, that's just how it has to be, and the right course is to aim at a dialog with OEMs about how to make it as convenient for everyone as possible, to aim at integrating a common functionality. Something like: every box can maintain a list of authorized keys, whatever ones the WHQL process entails, one unique to that box, one or more slots for installable keys.Microsoft has a strong financial incentive to minimize the convenience for other OS's, and I don't even think they can be faulted for pursuing that goal (*how* they do it, though, but that's irrelevant here). I think it's pretty clear that them tying the more restrictive conditions to a CPU architecture furthers that goal, and I think they should (as a matter of public policy, not just community goals) not be allowed to make that requirement unilaterally (and so broadly, not at all). I don't expect any of the above is new, just trying for a good summary.
About the install procedure Posted Jan 18, 2012 19:45 UTC (Wed) by drag (subscriber, #31333) [Link]
>The box will come pre-set to maintain/install Windows with a key that matches everything delivered from Microsoft and anybody Microsoft(?) likes.
If the system is sold with Windows pre-installed then this would be one of the few configurations that make sense.
The trick here if you want a Linux friendly setup then you must purchase your hardware from a Linux friendly vendor.
About the install procedure Posted Jan 18, 2012 21:44 UTC (Wed) by jthill (guest, #56558) [Link] The OEMs I was referring to above include everbody implementing UEFI code. Don't just dream big. The premise needs to be that this is a legitimate public policy matter (which it is).
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 19, 2012 1:36 UTC (Thu) by martin.langhoff (subscriber, #61417) [Link]
Greg K-H was mentioning on G+ what a fun time it'll be when one of the signing keys is compromised. There is no blacklist, no update mechanism. Oops!
He framed it in the context of liability (for the key issuers, facing the wrath of hw makers and downstream users). Pretty bad vulnerabilities in software haven't led to liabilities, even the CA breach fiasco recently doesn't seem to have led to legal action. So I am not sure about the liabilities angles.
But the mess... ooh, the MESS!
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 19, 2012 2:15 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
There is a blacklist, but there's currently no policy for updating it.
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 19, 2012 3:06 UTC (Thu) by laptop006 (subscriber, #60779) [Link]
What about mechanisms? Can a Windows update silently blacklist keys? (Or even add a new one?)
Garrett: Why UEFI secure boot is difficult for Linux Posted Jan 19, 2012 3:12 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
Keys can be added to the whitelist or the blacklist by updating the DB or DBX variables. Doing that requires that the update be signed by a valid KEK. Windows 8 logo machines will have a Microsoft key in KEK, so Windows Update can certainly add keys to either.
But live media won't be affected, right? Posted Jan 20, 2012 19:25 UTC (Fri) by blackbelt_jones (guest, #62623) [Link]
At this moment, I'm running KIARA GNU/Linux, my own remix of Slax 6.1.2 with virtually all of KDE 3.5.10 ported from Slackware 12.2. (I learned of this story from KNewsticker. Does anybody remember KNewsticker?) (http://www.kiaragnulinux.blogspot.com).
I run the root system from a usb thumbdrive, and I run a simple script (the only kind I know how to write) that mounts the hard drive as /home partition, and nudges me through the steps for recreating a normal user account, creating a new root password, and setting up sudo. It takes about two minues to relogin after a reboot. The root system runs on the thumbdrive, where nothing is ever overwritten by the system, only by me directly. (I've changed the default in the bootloader to "always fresh" mode.) My personal data and configuration files persist on the hard drive.
I call it "live rooting" I do it because, in theory, it adds a solid layer of security (The root system will always spring back into shape after a reboot) and because, in theory, old software needs extra security, as it may be more vulnerable.
As I understand it (and it's always possible that I don't) secure boot won't change that. The Live CD/USB has long been one of Linux's greatest advantages, but it's mostly been used as a "try before you buy" gimmick. Maybe this will be taken as an opportunity to create new Live Media that integrate with the hard drive to combine flexibility and security in a whole new way.
A slax USB has a "modules" directory, where *.tgz files can be added, and are loaded into the system at boot, and an *.iso can be generated for a new CD. Is there any reason why a similar method couldn't be created for *.deb files or *.rpm files? Usually, this is where someone tells me that it's already been done.
But live media won't be affected, right? Posted Jan 24, 2012 11:21 UTC (Tue) by salimma (subscriber, #34460) [Link]
At first glance, my reaction was "surely it should not matter if you're booting from a hard disk or from a removable USB medium; the same bootloader signature check should still be performed".
But then -- UEFI boots from a GPT-partitioned medium; USB thumb drives are typically using the older partition table format. I've not found a reference for it yet, but perhaps in Standard Mode, one can only boot from GPT media (and thus legacy live USB sticks can only be booted in Custom Mode)?
Garrett: Why UEFI secure boot is difficult for Linux Posted Feb 2, 2012 0:36 UTC (Thu) by Harland (guest, #52209) [Link]
As a protection and control engineer, it is necessary to now where the weak link in any chain of devices (protection scheme); and it is folly to think there is not a weak link, but you minimize the impact or security concerns when something fails (and failure is when, not if).
The whole chain of securing any application must start at the hardware (like true identity of a person as recorded by a system ultimately must fall back to metrics at birth, or false identities abound).
Once the key signing (identity privilege) of the boot process is established and 'trusted', the privilege can be passed up the instance chain, to where every process must by privileged (key signed) in order to execute. This has huge ramifications for F/OSS up to the application level (no more firefox on company computer =). Of course, vulnerabilities will always exist in the chain, privileged (or not?).
UEFI secure boot seems to be a 'fait accompli', and being touted as security, seems more about hardware control and thus no more hand me downs or reuse for that ARM mesh/cluster from cheap discarded phones. The freedom I have enjoyed (sweat and tears =) with linux is again being swindled into a compromise of privileges and immunities in the hope of security. It seems all we got left is a small voice to change the OEM hardware vendors to give us 'custom' mode options, but all the hardware that doesn't will be non-reusable garbage.
So at the end of this privilege chain, is me being able to use my hardware at someone else's behest. And the other end is tied to the physical hardware, which will require a physical device (castle, drawbridge) I have to interact with to gain its use. I hope and will support hardware vendors who will provide at least a dipswitch or maybe a 'cartridge' to plug-in enabling my free use and access.
I agree with the article authors comments as this is the compromise we are left with to get whats left, a privilege (not a right).
|
|||||||||||||