Weekly Edition
Return to the Security page
| |||||||||||||
Implementing UEFI Secure Boot in Fedora
On his blog, Matthew Garrett writes about plans for supporting UEFI secure boot in Fedora 18. In it he covers signing the first-stage bootloader with a Microsoft key, while signing GRUB 2, the kernel, modules, etc. with a Fedora key. It is a compromise to try to avoid problems for users who want to boot Linux on Windows 8 hardware. "The last option wasn't hugely attractive, but is probably the least worst. Microsoft will be offering signing services through their sysdev portal. It's not entirely free (there's a one-off $99 fee to gain access), but it's cheaper than any realistic alternative would have been. It ensures compatibility with as wide a range of hardware as possible and it avoids Fedora having any special privileges over other Linux distributions. If there are better options then we haven't found them. So, in all probability, this is the approach we'll take. Our first stage bootloader will be signed with a Microsoft key."
(Log in to post comments)
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 13:24 UTC (Thu) by sblack (subscriber, #81076) [Link]
I got the overwhelming impression from Matthew Garrett's talk[1] (title, "EFI and Linux: The Future is Here, and it's Awful") that the current EFI standard is so badly written and implemented that it amounts to security theater.
If that's the case, why are we pretending that this is a step forward, rather than a distasteful concession, given Microsoft's control of x86?
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 13:39 UTC (Thu) by ndye (subscriber, #9947) [Link] why are we pretending that this is a step forward, rather than a distasteful concession? I think of it as air-dropping food to hostages who "buy" a Windows 8 computer and want to exploit "their" hardware, while others fight on the front lines, perhaps demonstrating the theatrical aspects of insecurable UEFI implementations. But maybe that's just me.
Implementing UEFI Secure Boot in Fedora Posted Jun 1, 2012 7:38 UTC (Fri) by Cato (subscriber, #7643) [Link]
Traditionally, many people have tried out Linux by installing it as dual-boot on a Windows PC, so this is actually quite important to the Linux community. A world where Windows 8 PCs can't easily have Linux installed will see much less growth in Linux usage, at least on PCs - and of course Windows 8 on ARM is completely locked down a la iPad.
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 13:44 UTC (Thu) by dilinger (subscriber, #2867) [Link]
I don't think anyone is pretending that this is a step forward (well, other than Microsoft). From Matthew's blog post, "It's not the ideal outcome for anyone, and I'm genuinely sorry that we weren't able to come up with a solution that was better. This isn't as bad as I feared it would be, but nor is it as good as I hoped it would be."
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 14:00 UTC (Thu) by sblack (subscriber, #81076) [Link]
I do see that, but it seems that he's only bemoaning having to use Microsoft's key. Otherwise, it looks like Fedora is planning to take UEFI seriously:
"Next we'll be adding support for verifying that the kernel it's about to boot is signed with a trusted key. And finally we'll be sanitising the kernel command line to avoid certain bits of functionality that would permit an attacker to cause even a signed kernel to launch arbitrary code. These restrictions will all vanish if secure boot is disabled."
Taking it seriously Posted May 31, 2012 14:59 UTC (Thu) by corbet (editor, #1) [Link] There is value in the concept of ensuring that your computers are running only the software you want to be there. Beyond that, I can imagine that Red Hat has plenty of customers who would be entirely pleased to know that their systems will not boot if the kernel or bootloader have been tampered with. Yes, it's a feature worth taking seriously. UEFI has lots of problems, but so do the BIOSes that preceded it.The sticking point, is always, is who holds the keys. As long as the owner of a computer can control what runs on it, life is good. Retaining that control will be something we have to fight for, as always.
Taking it seriously Posted May 31, 2012 22:30 UTC (Thu) by ballombe (subscriber, #9523) [Link]
> There is value in the concept of ensuring that your computers are running only the software you want to be there.
Unfortunately, this value is 99$, so the proposed solution does not provide any security.
Taking it seriously Posted Jun 1, 2012 17:15 UTC (Fri) by AndreE (subscriber, #60148) [Link]
So would this scheme be better if the cost of signing was $100,000?
In any case, you aren't paying for a signing certificate, you are paying for Microsoft to analyse your and sign your binary. There is a difference.
Taking it seriously Posted Jun 1, 2012 0:31 UTC (Fri) by gmaxwell (subscriber, #30048) [Link]
Er. if you have access to the hardware you can just disable secureboot. If you don't— you'd have to first exploit the kernel to replace the bootloader/kernel, and if you can do that you don't have too much need to replace the bootloader/kernel. (Just put your rootkit in systemd so that it reexploits the system at every bootup).
(Though the the other person saying the keys cost $99— not so, you can manually install your own keys for free. The $99 is what it costs to get a key that will work on other people's hardware... though perhaps it's misleading to call it $99, it'll have to be $99 plus some kind of certification since I'm pretty sure malware authors can spare $99. I have no idea how they'll tell linux devs apart from malware authors other than by only licensing billion dollar Linux distributors)
Taking it seriously Posted Jun 1, 2012 16:42 UTC (Fri) by raven667 (subscriber, #5198) [Link]
> reexploits the system at every bootup
That can only happen after it starts running arbitrary user code, and even then the exploit can't modify anything signed or it wouldn't validate on the next bootup. Even in the case where someone has spend the $99 to sign malware you can identify and revoke it and break the re-exploitation cycle. The benefit is an immutable set of tools early in boot to clean out malware.
Taking it seriously Posted Jun 1, 2012 17:08 UTC (Fri) by AndreE (subscriber, #60148) [Link]
I don't believe this would work. UEFI in secure mode won't load a bootloader that isn't signed with a recognisable key. So you can't just replace the bootloader and be on your way.
As for physical access, well then yes in that case all bet's are off. If you have physical access rather than disable secure boot you should add your own key and run your self-signed malware silently.
Taking it seriously Posted Jun 1, 2012 17:24 UTC (Fri) by gmaxwell (subscriber, #30048) [Link]
You don't replace the bootloader. You replace the first unsigned thing that runs— in the solution described for Fedora this would be systemd. Systemd would then execute the kernel exploit and intercept IO from the update process in order to make updates invisibly fail.
You only get the benefit if you sign and lock down 100% of the software which will run before updates are applied from the network. Perhaps thats viable on windows, though I'm doubtful. Regardless, what's suggested for Fedora would not have that property.
Taking it seriously Posted Jun 1, 2012 17:37 UTC (Fri) by raven667 (subscriber, #5198) [Link]
Packages are already signed so extending the signature checking system much more widely is likely to happen. At the very least a small base could be validated, including enough to clear out malware and break the cycle of re-exploitation.
Taking it seriously Posted Jun 1, 2012 17:59 UTC (Fri) by gmaxwell (subscriber, #30048) [Link]
It's not at all the same kind of signing. The package signing is (IIRC) on the compressed data, and it requires the entire userspace stack to get to it (e.g. libc).
Taking it seriously Posted Jun 1, 2012 20:45 UTC (Fri) by raven667 (subscriber, #5198) [Link]
I understand that, what I was trying to communicate (poorly), is that if there was a system to include signatures with binaries that the kernel could check then the vast majority of userspace could be signed. We already deal with keys and signing for userspace software at the package level so it would only be an incremental extension on the systems which are already in place. Even though there would be security vulnerabilities in userspace that would allow malware to be injected through signed/verified software, there should be enough core, immutable tools to be able to clean it up. Without signature checking all the way from the firmware init you can't build an immutable infrastructure at all, with signatures you can (up until the point where you have an attack surface).
Taking it seriously Posted Jun 1, 2012 21:09 UTC (Fri) by gmaxwell (subscriber, #30048) [Link]
Fair enough— but stand back and think about that.
What makes Fedora strong compared to Microsoft? Microsoft is the dominant player, Microsoft can employ many more designers— and out spend Fedora in every way, Microsoft can set a more consistent vision for the developers of the software they ship. Microsoft can hire almost any talent they like. These are all formidable strengths and they have many others.
What can't Microsoft do? Their business model is fundamentally incompatible with giving users an operating system which they— or their designees— can easily and legally change. Microsoft can't deliver a self-contained self-hosting system that with a few commands can patch and recompile anything it runs. It's incompatible for giving users access to the complete source code for everything they run, thus lowering the learning curve and turning out an endless stream of new developers.
Linux distributions could start engaging in top to bottom signing of userspace binaries— but in doing so it would be weakening the strengths of the open world and playing into pattern of top down control which they are fundamentally better at. Even if there are magic buttons and procedures you can add to regain these freedoms, and even if you ignore that one of the most important software freedom's is the freedom to share the results of your modifications and have other people able to use them easily... the additional friction of having to disable that 'security' diminishes our communities advantages.
There absolutely are applications for locked down machines where doing so provides a distinct advantage to the owner of the machine. But these applications are not typical for Fedora. I think it would be arguably in the GNU/Linux communities long term to leave those markets to special case distributions— or even to Microsoft.
I strongly support improved security— but there are a great many things which can be done to provide a more material improvement than codesigning without the compromises. The immutable boot only lets the horse be put back in the barn without reimaging the system— but by then it may be too late. At the point of initial compromise the users data may have been copied and erased, their bank accounts emptied, bitcoins stolen, whathave you.
If all you really care about is making sure that botnets don't persist then perhaps secureboot plus a sufficient amount of signed userspace is enough. But it's pretty weak from the perspective of actually securing the user.
We're hardly making use of SELinux, for example— Why are programs like Pidgin, Evince, and Firefox able to access my home directory except via a carefully audited privileged separated filechooser app? Why aren't they running in a sandbox? Why have we not built accelerated versions of tools like valgrind which are able to provide even stronger sandboxing than SELinux around the most vulnerable code? I could fill pages of things which would provide more security improvement for users than code signing without diminishing our fundamental advantage vs the closed software world. If it's security we're trying to get— why would we first do the one thing that makes us more like Microsoft?
Taking it seriously Posted Jun 2, 2012 4:48 UTC (Sat) by raven667 (subscriber, #5198) [Link]
I think we are having a good discussion here. Yay!
> What makes Fedora strong compared to Microsoft? [...] Microsoft can [...] out spend Fedora in every way, Microsoft can set a more consistent vision for the developers of the software they ship.
MS can do extensive QA and UX testing but they don't have a monopoly on smart people or good designs and in my judgement MS seems pretty poor at having a vision and organizing their labor in any sensible way. Their recent attempt at coherence around "Metro" is a refreshing exception for a company who's major applications all use different custom UI toolkits that only superficially resemble each other.
> Their business model is fundamentally incompatible with giving users [...] access to the complete source code for everything they run
The industry behaves as if this were true so for practical purposes it is true but RedHat shows that there is plenty of business in selling the binaries while giving away the source, protected by Trademark more than Copyright, although the success of other Linux business indicates that there may only be room for one major player selling binaries based on the same source as other minor players.
> Linux distributions could start engaging in top to bottom signing of userspace binaries— but in doing so it would be weakening the strengths of the open world [...] the additional friction of having to disable that 'security' diminishes our communities advantages.
I don't believe this at all. As long as you can load your own keys or disable the secure boot from the physical machine then anyone who is a "developer" and wants to work with source can do so. I think working with source is a much bigger hurdle than changing a firmware setting or a jumper or loading a key.
> I think it would be arguably in the GNU/Linux communities long term to leave those markets to special case distributions— or even to Microsoft.
I disagree again. Having user unfriendly defaults is not in the long term interest of GNU/Linux. Making all users, including non-developers, go through what you yourself describe as "additional friction" and then not taking advantage of available technology is not a positive thing. To re-iterate, I don't think the additional friction of modifying secure boot is a problem for developers but I do think it is a (small, unnecessary) problem for non-developer users.
> I strongly support improved security
I do too.
> but there are a great many things which can be done to provide a more material improvement than codesigning without the compromises.
It doesn't have to be either/or, that's a false dichotomy
> The immutable boot only lets the horse be put back in the barn without reimaging the system— but by then it may be too late. At the point of initial compromise the users data may have been copied and erased, their bank accounts emptied, bitcoins stolen, whathave you.
Yep, that's all its trying to do, it doesn't cure cancer or cook a perfect steak either.
> We're hardly making use of SELinux, for example— Why are programs like Pidgin, Evince, and Firefox able to access my home directory except via a carefully audited privileged separated filechooser app? Why aren't they running in a sandbox? Why have we not built accelerated versions of tools like valgrind which are able to provide even stronger sandboxing than SELinux around the most vulnerable code?
This is a whole 'nother discussion. It would be great if we could do a ground-up re-design of how operating systems and applications work to help enforce this kind of sandboxing and seperation. I think that ultimately, in the coming decades, so much of application technology is going to be sucked into the web browser that this is the place to focus, as is being done in all the major browsers.
> If it's security we're trying to get— why would we first do the one thing that makes us more like Microsoft?
I am not primarily a MS technology user, apparently I'm obligated to say that up front, but it's not productive to act like MS has cooties or something. One sees the same thing whenever a discussion of Mono comes up. They may be stupid and evil on many levels but that doesn't mean that all their technology is bad or that changes they make to the marketplace can't be put to good use. All this crypto stuff can be used for both evil and good purposes, the fact that bad things can be done doesn't mean that we shouldn't do the good things.
Taking it seriously Posted Jun 1, 2012 18:01 UTC (Fri) by AndreE (subscriber, #60148) [Link]
You're right...extending it to init at least is needed
Taking it seriously Posted Jun 1, 2012 18:14 UTC (Fri) by gmaxwell (subscriber, #30048) [Link]
At a minimum, but realistically network manager too, since you need to be able to get updates before any unsigned code runs. $ ldd /usr/bin/nm-tool | wc -l ... returns 30 libraries.
I suppose that init could implement simple dhcp support and a cutdown emergency updater. But this is just a lot more stuff and a big change from how things work in Linuxland.
Taking it seriously Posted Jun 1, 2012 20:26 UTC (Fri) by nybble41 (subscriber, #55106) [Link]
You don't really need to validate the channel over which the update is downloaded (which would essentially require validating the entire Internet). You just need to validate the signature on the update itself before applying it, which can be done with a much smaller core of verified code.
The unverified code could _block_ the update, of course, but that could happen anyway: upstream ISP blocks the connection, someone pulls the physical ethernet plug, system experiences a DoS attack, etc. If this is a problem, the secure boot code could require a new, signed update after a given number of reset cycles. The update server would need to attest that the update is current, e.g. by signing the reset count at the time the update was downloaded, signed in turn by the boot code.
Taking it seriously Posted Jun 1, 2012 20:49 UTC (Fri) by gmaxwell (subscriber, #30048) [Link]
I'm not saying you have to validate the channel, I'm saying that you can't execute any unsigned code in order to get access to the channel. At least with our current software infrastructure in Fedora we're using millions of lines of code before we can get a system online.
Otherwise— if unsigned code runs before updates— the unsigned code will have been modified by the attacker, it will execute a kernel exploit, and the exploit will undermine the update process— not just DOS it but make it look successful while keeping the machine compromised.
Or to put it more simply— What _goal_ (not mechanism) of an attacker will SecureBoot in Fedora thwart. It's advertised on windows as preventing unremovable rootkits, but I've explained why it can't do that at least on Fedora/Linux without signing a substantial hunk of userspace or moving a lot of networking code into init/systemd.
Taking it seriously Posted Jun 1, 2012 21:37 UTC (Fri) by nybble41 (subscriber, #55106) [Link]
> Otherwise— if unsigned code runs before updates— the unsigned code will have been modified by the attacker, it will execute a kernel exploit, and the exploit will undermine the update process— not just DOS it but make it look successful while keeping the machine compromised.
Not if the update process is sane. The unsigned code connects to the Internet, downloads the signed update, and stores it somewhere the boot code can access. You then reboot into a known-good state, and the signed and validated boot code checks the signature on the update and, if the signature is valid, applies it. The kernel never has write access to the secure boot parameters, so a kernel exploit can't undermine the update process beyond blocking the update.
To address that case, when the last valid update becomes too old the system can refuse to boot in secure mode, which should be fairly noticeable. A less drastic measure would be for the secure code to simply report the release date of the last update on startup, though that requires you to trust your display path.
Taking it seriously Posted Jun 2, 2012 6:54 UTC (Sat) by dilinger (subscriber, #2867) [Link]
After my exploit takes over the system, I replace your unsigned code with my own. It pretends to download the secure update, but either a) doesn't, or b) just re-downloads an older (still exploitable, and very much signed/valid) update.
You then reboot into a known-good state, and the signed and validated boot code checks the signature on the update and.. whoops, there is no update (or we apply an older update if the user expects to see something happen). The system boots up, the exploit is re-run, and the user has no idea that they're still running an old version.
Taking it seriously Posted Jun 4, 2012 4:43 UTC (Mon) by raven667 (subscriber, #5198) [Link]
I don't understand why a secured, trusted process would have a dependency on an exploitable unsecured process. That doesn't seem like a sane design
Taking it seriously Posted Jun 2, 2012 3:48 UTC (Sat) by raven667 (subscriber, #5198) [Link]
> I've explained why it can't do that at least on Fedora/Linux without signing a substantial hunk of userspace
I think you're expecting the cart to be in front of the horse. Of course you only have a trusted code path as far as you've implemented a trusted code path. There is no point in implementing the userspace or even kernel checking until the lower layers are done because you could always hide a persistant rootkit one layer down than what you are checking. Building on the secure boot framework, now that it exists, will allow the other checks to happen, but it is not that implementation.
Taking it seriously Posted Jun 4, 2012 14:21 UTC (Mon) by hummassa (subscriber, #307) [Link]
> There is value in the concept of ensuring that your computers are running only the software you want to be there.
Unfortunately, this is not possible.
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 13:45 UTC (Thu) by carenas (subscriber, #46541) [Link]
IMHO because the alternative would be to not have Linux booting at all if secure booting is enabled and which is likely to be the default with windows 8 provided systems.
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 15:02 UTC (Thu) by hitmark (guest, #34609) [Link]
Question is if one has more of a leg to stand on with or without the implementation. In the end i guess we end up with the age old "open source vs free(dom) software" debate.
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 13:46 UTC (Thu) by thumperward (guest, #34368) [Link]
Right now, anyone can burn a Linux distro install CD, boot a PC fresh from the store from it and install the distro with zero or minimal pre-configuration (the only potential barrier being the BIOS boot order). It would be a step backwards not to be able to do that any more, which is the reality as soon as UEFI secure boot is enabled on new PC hardware (absent the work detailed in the article). This is likely to happen within a timespan of months.
Yes, in this case Linux is having to run as fast as it can just to stay in the same place. But there simply isn't an alternative. OEMs are not going to sacrifice their "Certified for Windows 8" stickers based on political pressure from the Linux desktop distributions. And users who are told that the only way to install Linux is to fiddle about in their computer settings in order to disable a security feature will simply not install Linux.
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 14:42 UTC (Thu) by pboddie (subscriber, #50784) [Link]
And once again we may ask where the regulatory authorities are.
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 15:02 UTC (Thu) by thumperward (guest, #34368) [Link]
On the platform upon which Microsoft has a monopoly on operating systems, the standard mandates that users be able to install their own keys (and thus be able to use the secure channel) or else disable secure boot. Moreover, Microsoft is not dictating that OEMs preinstall only Microsoft's key, or indeed that they preinstall it at all. It's all very well shouting "monopoly!" given the undoubted advantage this gives Microsoft over other OS vendors, but the standard already offers sufficient concessions to said vendors that they are not being shut out of x86 entirely. It's difficult to see what a regulatory body could add to that.
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 18:20 UTC (Thu) by pboddie (subscriber, #50784) [Link]
Microsoft never openly dictates what OEMs do, but the OEMs still manage to fall into line. Should no-one wonder why that is?
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 18:31 UTC (Thu) by thumperward (guest, #34368) [Link]
They are not "falling in line". They are "doing the bare minimum required to sell their product". And for the more Slashdot-prone in the audience, it is in fact the case that the sort of thing which saw Microsoft actually sanctioned for abusing their monopoly *was* "openly dictating what OEMs do", in the form of forbidding them to allow for dual boots at all. MS are being clever here and allowing simple economics to achieve the hoped-for result.
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 20:57 UTC (Thu) by drag (subscriber, #31333) [Link]
Yes. What Microsoft did that got them into trouble was restricting access to their software for companies that were selling rival operating systems.
So if you had a store and you were selling BeOS systems and Microsoft decided that they didn't like it then you would not only have to pay more for your Microsoft software you would get it later then your competitors which put you at in a potentially significant disadvantage.
Personally I think that they should of just let Microsoft do whatever they wanted. The whole lawsuit was just one fairly evil proprietary software company fighting against another fairly evil proprietary software corporation.
The difference between Microsoft and it's failed competition was not due to Microsoft being evil or monopolistic practices. They were all immoral. Microsoft was simply better ran company which sold cheaper software.
Implementing UEFI Secure Boot in Fedora Posted Jun 1, 2012 12:01 UTC (Fri) by pboddie (subscriber, #50784) [Link]
I guess you both don't remember the days when Microsoft insisted on being paid licensing fees for every x86 CPU shipped in a computer regardless of whether any software was being provided at all, apparently justified after the fact by the same argument that has people paying the music and movie industries every time they buy blank media because they are, of course, going to use it to copy music and movies.
Whether such practices are enforced overtly or through "incentives" is not a distinction that should automatically determine whether a regulator should take action or not.
Implementing UEFI Secure Boot in Fedora Posted Jun 1, 2012 17:04 UTC (Fri) by apoelstra (subscriber, #75205) [Link]
>Whether such practices are enforced overtly or through "incentives" is not a distinction that should automatically determine whether a regulator should take action or not.
It is, though, for the following reason:
"Incentive" implies some sort of trade-off (for example, Microsoft's bullying makes their software less useful and them less trustworthy, and they know they can only go so far before OEM's find it profitable to start selling no-OS or Linux systems).
It also requires the trade-off to be sustained for as long as Microsoft wants people to produce computers with their keys. So if Microsoft were to become a much smaller player in the market one day -- and looking at Windows 8, I expect this to happen soon -- they would be forced to stop pulling this crap.
To contrast, your example of us paying media companies for blank media, has none of the above. It was imposed by regulators (congress/parliament), working for a cabal of other regulators (RIAA/MPAA) with no trade-off, no choice, no accountability and no time limit. The fact is that the record companies would have failed years ago with such a poor business model, and the only reason they are alive today is because of regulatory capture.
Implementing UEFI Secure Boot in Fedora Posted Jun 1, 2012 19:43 UTC (Fri) by pboddie (subscriber, #50784) [Link]
Firstly, you haven't really made the case for the distinction. Of course an incentive is a trade-off, but it's really just a way of pursuing the same policy without forcing anyone (the vendors or regulators) to take drastic action.
If vendors refused to follow any rules laid down by Microsoft, then Microsoft might deny them the ability to bundle Windows (technically or contractually), and that would potentially force them to look elsewhere for business or to complain about it to a higher power. However, since most vendors are heavily dependent on being able to provide Microsoft products because of the retail climate being distorted in the company's favour, most would be likely to go along with almost anything.
Offering incentives instead of making threats allows Microsoft to look like the good guy whilst making the transaction look like a positive thing, even though the effect of not taking up Microsoft's "generous" offer will result in relegation to a disadvantaged position for any vendor not wishing to play along.
And my example about blank media was concerned with per-processor licensing fees. The "justification" for this was that people would always be running Windows but might refuse to pay for it bundled, and that Microsoft should therefore get a guaranteed fee as compensation for all those "pirates" who couldn't possibly want to run anything else. The regulators put a stop to this, but then Microsoft went and integrated DOS and Windows shortly afterwards, so it was merely a tactical retreat to prevent more serious regulatory measures being imposed that might undermine that very strategy.
Implementing UEFI Secure Boot in Fedora Posted Jun 1, 2012 13:59 UTC (Fri) by mcoleman (guest, #70990) [Link] Re "It's difficult to see what a regulatory body could add to that.", let me help you out.They could forbid this anti-competitive behavior.
Implementing UEFI Secure Boot in Fedora Posted Jun 1, 2012 14:34 UTC (Fri) by thumperward (guest, #34368) [Link]
What "anticompetitive behaviour" are just suggesting be "forbidden" here? Do you suggest that a regulatory body could ban OEMs from shipping Microsoft's key, or demand that UEFI secure boot be disabled by default on all new computers, or that the Unified EFI Forum itself be disbanded and the standard torn up?
It is not difficult for any moderately intelligent person to see that at each stage, Microsoft has plenty of wiggle room in stating that choices are provided and that competitors are not locked out. Microsoft's lawyers would have no difficulty whatsoever in impressing that upon any regulatory body.
Implementing UEFI Secure Boot in Fedora Posted Jun 1, 2012 16:46 UTC (Fri) by raven667 (subscriber, #5198) [Link]
Those are absurd suggestions, straw men to be easily dispatched. Other articles from Matt Garret discussed some alternative approaches to UEFI key management that could make this feature more vendor and user friendly that you may be interested in reading.
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 16:02 UTC (Thu) by drag (subscriber, #31333) [Link]
> And once again we may ask where the regulatory authorities are.
The regulatory authorities are happily making the situation vastly worse with implementing things like DMCA, ACTA, software patents, wiretapping efforts, copyright enforcement, etc etc.
They are not on your side. They will never be on your side.
Their purpose in life is just to do whatever will benefit themselves above all else and will happily side with whoever is able to provide them the most benefit. This usually is with whatever group will offer the most interesting chances at monetary and power gains.
Implementing UEFI Secure Boot in Fedora Posted Jun 1, 2012 1:00 UTC (Fri) by nix (subscriber, #2304) [Link]
Yes, thank you, we all know your tiresome politics by now. Can't you take it to a blog post or something?
Implementing UEFI Secure Boot in Fedora Posted Jun 2, 2012 11:59 UTC (Sat) by efraim (subscriber, #65977) [Link]
Actually I found the grand-parent post informative. Policy discussions (such as regulations) ARE inherently about politics.
So I would appreciate if you stop shutting up whoever voices a position you do not agree with. Though I rarely post here I read the comments here a lot and I usually find your posts quite enlightening - this one is not.
Implementing UEFI Secure Boot in Fedora Posted Jun 4, 2012 12:55 UTC (Mon) by nix (subscriber, #2304) [Link]
It's not that I disagree with his position, it's that he has only one position, and never backs it up beyond (as far as I can tell) an axiom that everything governments do is ipso facto bad while if a corporation does the exact same things it is ipso facto not bad, or at least not worth caring about. These axioms are sufficiently far removed from the realities of present-day political systems as not to be worth basing anything but pie-in-the-sky discussions on.
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 18:22 UTC (Thu) by nickbp (subscriber, #63605) [Link]
They're in the continual process of being de-funded.
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 19:06 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link] And once again we may ask where the regulatory authorities are. In the pockets of the industries they're supposed to be regulating- exactly where the rich and powerful want them to be.
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 20:47 UTC (Thu) by drag (subscriber, #31333) [Link]
It makes it easier to understand what is going on when you realize that the people that run the regulatory agencies and the people that run the companies that are suppose to be regulated are pretty much the same group of people.
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 13:44 UTC (Thu) by dmitrij.ledkov (subscriber, #63320) [Link]
I want to sign my own bootloader with my GPG key and have a boot time web of trust back to the archive and the packages that run on my laptop.
Somehow I do not want Microsoft to effectively hold a kill switch to my hardware. Please explain, if I got it wrong.
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 13:52 UTC (Thu) by thumperward (guest, #34368) [Link]
As the article states, on x86 hardware the UEFI secure boot specifications require the ability to install one's own keys to be present. This is absent on ARM (where the specification does not even require the ability to disable secure boot, meaning that signed keys and only signed keys will ever work), but it's to be hoped that Microsoft's monopoly over operating systems on commodity x86 hardware never extends to commodity ARM hardware (where Linux is overwhelmingly dominant at present).
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 14:04 UTC (Thu) by cortana (subscriber, #24596) [Link]
I believe the spec is worse than this: OEMs are forbidden from allowing the user to install their own keys or disable Secure Boot entirely!
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 14:21 UTC (Thu) by thumperward (guest, #34368) [Link]
Quite. On the other hand, it's not uncommon for non-x86 devices to be locked already, and unlockable ones are still the exception. The most popular phone and tablet in the world are not only locked, but controlled by a vendor that actively tries to re-lock devices that are unlocked.
On ARM it's almost always been the case that installing Linux has involved fiddling at least and outright cracking at most. MS legislating that one can't allow the bootloader to be unlocked makes no difference if the vendors don't currently allow that anyway.
The important use case here remains "putting a CD into an x86 system", because those are the only ones where a) Microsoft has a monopoly and b) installing Linux is never more complicated than sticking a CD in the tray and rebooting.
Implementing UEFI Secure Boot in Fedora Posted Jun 1, 2012 16:53 UTC (Fri) by raven667 (subscriber, #5198) [Link]
Linux is much more dominant in the ARM space and while many devices are locked, most vendors also make unlocked SKUs and for some unlocked devices are the rule and not the exception. It would be good to encourage vendors making UEFI ARM devices to make an unlocked SKU without the Win8 logo at least in small runs for developers that can be sold at-cost.
Implementing UEFI Secure Boot in Fedora Posted Jun 1, 2012 21:04 UTC (Fri) by cjwatson (subscriber, #7322) [Link]
It's not the UEFI specification that makes this requirement; it's the Windows 8 logo requirements. I think it's quite important to be careful about that distinction.
Implementing UEFI Secure Boot in Fedora Posted Jun 2, 2012 4:57 UTC (Sat) by raven667 (subscriber, #5198) [Link]
It is good to be precise but MS is the elephant in the room, it doesn't matter what the specification says, it matters what the MS implementation does because that is the de-facto standard, at least in markets they dominate.
Implementing UEFI Secure Boot in Fedora Posted Jun 2, 2012 8:59 UTC (Sat) by cjwatson (subscriber, #7322) [Link]
Sure - I just think that we do ourselves a disservice by not making it clear when something is due to Microsoft's requirements rather than due to the standard. Standards (however much influenced by corporate interests) are a powerful force in many people's views, and one often needs a good reason to diverge from them; so let's not invest Microsoft's policy with the further force of standards for them, when in fact in this case the standard doesn't specify a particular policy.
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 15:17 UTC (Thu) by cesarb (subscriber, #6266) [Link]
So, if you write a new operating system for x86 PCs, and want to distribute it to a non-technical public (thus having to be able to boot directly from the install media without extra steps), you need to have it signed by Microsoft.
That reminds me of an old science-fiction story...
"[...] you could not install one if you had one, without knowing your computer's root password. And neither the FBI nor Microsoft Support would tell you that." -- https://www.gnu.org/philosophy/right-to-read.en.html
And by the way, who really believes the signing service will stay the same forever? How long before the price increases? How long before the requirements increase, like not allowing users to run non-sandboxed unsigned code? And how long before competitor keys start being blacklisted, with some flimsy excuse ("your kernel was used by someone to bypass Windows DRM and copy a DVD, so we are revoking your privileges")? Finally, how long before the ability to disable secure boot is removed also from x86, like it will be on ARM?
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 15:19 UTC (Thu) by thumperward (guest, #34368) [Link]
> And by the way, who really believes the signing service will stay the same forever? How long before the price increases? How long before the requirements increase, like not allowing users to run non-sandboxed unsigned code? And how long before competitor keys start being blacklisted, with some flimsy excuse ("your kernel was used by someone to bypass Windows DRM and copy a DVD, so we are revoking your privileges")? Finally, how long before the ability to disable secure boot is removed also from x86, like it will be on ARM?
Most of Slashdot's commentators. That's probably the best place to indulge one's ruminations on such.
Implementing UEFI Secure Boot in Fedora Posted Jun 1, 2012 11:29 UTC (Fri) by AndreE (subscriber, #60148) [Link]
Nothing is more Slashdot-esque than a guy going around telling other people they should go to Slashdot.
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 16:40 UTC (Thu) by butlerm (subscriber, #13312) [Link]
If signing bootloaders is a necessary evil, surely the proper thing to do would be to assign the responsibility to an independent body rather than a vendor with a substantial conflict of interest?
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 16:52 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
Which independent body did you have in mind?
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 17:00 UTC (Thu) by dgm (subscriber, #49227) [Link]
The Apache Foundation seems to be en vogue lately.
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 22:24 UTC (Thu) by ncm (subscriber, #165) [Link]
The Apache Foundation is where projects go to die.
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 23:53 UTC (Thu) by dgm (subscriber, #49227) [Link]
Do you need a better reason?
Implementing UEFI Secure Boot in Fedora Posted Jun 1, 2012 12:06 UTC (Fri) by pjones (subscriber, #31722) [Link]
We'd be happy to see them volunteer for this.
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 17:34 UTC (Thu) by butlerm (subscriber, #13312) [Link]
Distributing vendor keys to every hardware manufacturer on the planet is eminently unscalable, of course. It is clearly in the general interest that the keys that every system needs to carry come from an independent signing body. A vendor like Microsoft could change its policies overnight for a variety of reasons.
The first alternative that comes to mind is a hardware manufacturers association like the PCI-SIG. The IEEE sounds like a reasonable possibility as well. Another option might be to have a centralized body carry only a list of keys that "every" device should carry, and have the actual signing be done by independent key signing authorities like Verisign. Decide on a realistic number of standard authoritative keys (a dozen perhaps) and let KSAs bid for the privilege of providing one of them.
Of course it would nice to have a trusted non-profit KSA, provided one could come up with the necessary resources to operate one. If a sufficient number of vendors agreed, they could form a non-profit KSA and dispense with the need for independent for-profit KSAs to do the job instead. Either way, some independent organization needs to be in charge of the list of keys to be installed on essentially every device.
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 21:00 UTC (Thu) by bronson (subscriber, #4806) [Link]
And how long do you expect it to remain independent?
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 22:24 UTC (Thu) by butlerm (subscriber, #13312) [Link]
Why wouldn't a multi-vendor non-profit organization remain independent? Independence is the only reason why most of them exist. No one trusts individual vendors to be neutral in matters like these, because there are obvious conflicts of interest.
However, as of today, there probably isn't a single independent organization that is set up to run an operation like this. So the vendors that care are likely to have to either establish a new non-profit key signing authority, persuade an existing non-profit like the Apache Foundation to take on the job (with the appropriate contributions of time and resources), or establish a private for-profit key signing model where multiple independent, for-profit KSAs (think Verisign) have the ability to validate and sign binaries on a fee for service basis.
As it stands, from a multi-vendor point of view, it is unbelievable how poorly this was thought out. It is so bad that the whole scheme could probably be shut down on anti-trust grounds alone. It is a de facto conspiracy in restraint of trade.
Implementing UEFI Secure Boot in Fedora Posted Jun 1, 2012 0:12 UTC (Fri) by paravoid (subscriber, #32869) [Link]
What about the Linux Foundation? I'm sure you didn't me to tell you that idea, so what was the problem with that, if you are at liberty to say?
Implementing UEFI Secure Boot in Fedora Posted Jun 1, 2012 17:52 UTC (Fri) by dashesy (subscriber, #74652) [Link]
Google is not independent, they sure want the ARM market for android kernel, so why not the x86 world?
This will at least minimize the conflict of interest. They can leverage their ARM advantage to the benefit of the whole community, good karma and more market influence.
Implementing UEFI Secure Boot in Fedora Posted Jun 1, 2012 16:54 UTC (Fri) by raven667 (subscriber, #5198) [Link]
I gathered from the article that this was tried and no-one stepped up.
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 17:02 UTC (Thu) by raven667 (subscriber, #5198) [Link]
I too wish that they would also have used their influence to get the Fedora key installed by default in some systems, in addition to signing a boot loader with the MS key. My concern is that if there aren't any non-MS keys installed in UEFI by default from the beginning that the ability to add and manage those keys will atrophy, break and become unsupported. There is a cheap signing service now but that could be pulled at any time and the existing keys blacklisted leaving Fedora and others out in the cold without a plan B if the ability to boot with secure boot off or with a non-MS key becomes broken in the future.
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 17:30 UTC (Thu) by mjg59 (subscriber, #23239) [Link]
Binaries can only be signed with a single key. There's no way to produce install media that will work with two different signing keys.
Implementing UEFI Secure Boot in Fedora Posted May 31, 2012 21:20 UTC (Thu) by raven667 (subscriber, #5198) [Link]
I think I understand the issues around that and how it commits you to using the one key you can rely on, at least to install, but does that mean you shouldn't pursue getting your own key in there as well? Once a vendor does the work of pre-loading keys they will likely ship on all subsequent devices, that should lead to increasingly complete hardware coverage over the next 5 years or so. It might also eventually lead to the couple of best funded organizations who can get their keys pre-loaded becoming competitive peer authorities creating a marketplace that is not so critically dependent on the continued benevolence of one vendor.
Implementing UEFI Secure Boot in Fedora Posted Jun 1, 2012 0:08 UTC (Fri) by slashdot (guest, #22014) [Link]
So, Microsoft is willing to sign anything with their keys as long as you pay?
Or if not, how do they check whether the GRUB2 binary Mr. Garrett will submit to them doesn't contain backdoors?
Implementing UEFI Secure Boot in Fedora Posted Jun 1, 2012 1:49 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
They can't. So they'll just revoke your key and blacklist your company.
Implementing UEFI Secure Boot in Fedora Posted Jun 1, 2012 2:26 UTC (Fri) by slashdot (guest, #22014) [Link]
Is there really a revocation system for secure boot?
The way the system is described, it gives me the impression that there is just a static key/certificate, and you can't blacklist anything.
Implementing UEFI Secure Boot in Fedora Posted Jun 1, 2012 2:35 UTC (Fri) by jk (guest, #31383) [Link]
There is indeed a revocation system: software is able to add blacklist entries, which may be a hash of a binary, or a key (revoking access to all binaries relying on that key).
However, updating the revocation lists requires your updates to be signed with a key that is already present in firmware.
Implementing UEFI Secure Boot in Fedora Posted Jun 1, 2012 0:40 UTC (Fri) by Trelane (subscriber, #56877) [Link]
How will this affect Linux companies e.g. ZaReason and System76, which are dependent upon ODMs for the base configs?
Perhaps this is yet another reason to stop buying Windows PCs to run Linux.
Implementing UEFI Secure Boot in Fedora Posted Jun 1, 2012 7:27 UTC (Fri) by thumperward (guest, #34368) [Link]
System76 will be able to insert their own keys into the firmware prior to shipping. Nevertheless, as software can only be signed by a single key, the pragmatic approach described in the article (i.e. signing using Microsoft's key, which is virtually guaranteed to be present) will inevitably result in the likes of Ubuntu shipping using Microsoft's signature anyway.
Implementing UEFI Secure Boot in Fedora Posted Jun 2, 2012 8:00 UTC (Sat) by csamuel (✭ supporter ✭, #2624) [Link] It won't affect them at all (other than increase their share of the market of people who want PCs that are easy to install Linux on) as they have no reason to sell systems that have the Windows logo and so they can ship with secure boot disabled from the get go. As Cathy, the founder of ZaReason, said on Twitter: what, did you see me smiling all the way from AU? It'll make it easier for GNU/Linux-specific hardware. Sigh of happy It's time for people like us who value our freedoms to switch where we get our hardware from.
Implementing UEFI Secure Boot in Fedora Posted Jun 2, 2012 9:45 UTC (Sat) by fsphil (guest, #44932) [Link]
So what happens when Microsofts private key is leaked?
Implementing UEFI Secure Boot in Fedora Posted Jun 2, 2012 13:58 UTC (Sat) by spaetz (subscriber, #32870) [Link]
> So what happens when Microsofts private key is leaked?
Ahh, finally a useful use for distributed.net and their cracking tasks :-)
Implementing UEFI Secure Boot in Fedora Posted Jun 4, 2012 4:47 UTC (Mon) by raven667 (subscriber, #5198) [Link]
That seems pretty unlikely unless they are completely incompetent in handling the keys, the security requirements around a major CA are tedious but not rocket science.
Implementing UEFI Secure Boot in Fedora Posted Jun 4, 2012 9:59 UTC (Mon) by dgm (subscriber, #49227) [Link]
In tedium lies human error. That's why we use machines for repetitive tasks.
Implementing UEFI Secure Boot in Fedora Posted Jun 4, 2012 12:49 UTC (Mon) by nix (subscriber, #2304) [Link]
Didn't they just revoke two signing keys which were apparently leaked(?) and used to sign the Flame malware?
Implementing UEFI Secure Boot in Fedora Posted Jun 4, 2012 14:35 UTC (Mon) by hummassa (subscriber, #307) [Link]
How much time do you think it will take for Flame's creators to re-sign it with another "leaked" key?
Implementing UEFI Secure Boot in Fedora Posted Jun 4, 2012 18:13 UTC (Mon) by nix (subscriber, #2304) [Link]
They probably already had a resigned version ready to go, so, negative time.
Implementing UEFI Secure Boot in Fedora Posted Jun 2, 2012 10:29 UTC (Sat) by micka (subscriber, #38720) [Link]
So, why not just sign a bootloader that will boot any kernel, be it signed or not ?
The only interesting thing a bootloader does is allowing to choose the OS. If it doesn't allow you to choose between your 2 or 3 distributions, then don't use a bootloader at all.
Because if I understand the plan correctly, the bootloader would be able to boot a kernel from only one signer.
Implementing UEFI Secure Boot in Fedora Posted Jun 2, 2012 14:11 UTC (Sat) by DavidS (subscriber, #84675) [Link]
Because a bootloader which will load _anything_ will be blacklisted faster than you can say "Secure Malware Boot".
As it should.
Implementing UEFI Secure Boot in Fedora Posted Jun 2, 2012 16:25 UTC (Sat) by micka (subscriber, #38720) [Link]
> As it should.
I suppose we won't agree on this.
This equates "malware" with "unsigned software", while it's trivially false.
Implementing UEFI Secure Boot in Fedora Posted Jun 2, 2012 17:25 UTC (Sat) by mjg59 (subscriber, #23239) [Link]
Malware is a subset of unsigned software. If you can mechanically distinguish between unsigned malware and unsigned white hat software, I suspect there's a very big bag of money waiting for you somewhere.
Implementing UEFI Secure Boot in Fedora Posted Jun 2, 2012 17:33 UTC (Sat) by micka (subscriber, #38720) [Link]
Sure, but this criteria has an exceptionally bad (high) false positive rate.
Implementing UEFI Secure Boot in Fedora Posted Jun 2, 2012 17:36 UTC (Sat) by mjg59 (subscriber, #23239) [Link]
That's true, but the obvious alternative has an unacceptable (>0) false negative rate.
Implementing UEFI Secure Boot in Fedora Posted Jun 2, 2012 17:59 UTC (Sat) by micka (subscriber, #38720) [Link]
OK, let's say it like that : some people who install wireshark/nessus/whatever use it to crack into systems, so people should be forbidden to get those programs...
That's the same reasoning.
Implementing UEFI Secure Boot in Fedora Posted Jun 2, 2012 18:02 UTC (Sat) by mjg59 (subscriber, #23239) [Link]
Nobody's forbidding anyone from running anything. It's a matter of default policy. The default policy being imposed here is that only signed code should be able to directly influence hardware behaviour. Signing a bootloader that then executes unsigned code is a pretty obvious circumvention of that policy.
Implementing UEFI Secure Boot in Fedora Posted Jun 2, 2012 23:42 UTC (Sat) by hummassa (subscriber, #307) [Link]
> Malware is a subset of unsigned software.
Wrong.
I can be an authorized developer and erroneously sign a piece of software that contains some malware. Typical cases being disgruntled employers pushing vulnerabilities obfuscated in source code, and another example being the development/deployment machine being infected and infecting all generated executables prior to signing -- this way the malware is always present and always signed.
> If you can mechanically distinguish between unsigned malware and unsigned white hat software, I suspect there's a very big bag of money waiting for you somewhere.
There is no way (signatures or not) to distinguish malware from white hat software. It's an undecidable problem even to be solved by humans. The referred bag of money will stay put for a loooooooooong time.
Implementing UEFI Secure Boot in Fedora Posted Jun 3, 2012 0:19 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
>I can be an authorized developer and erroneously sign a piece of software that contains some malware.
Then you won't be authorized developer for long.
In reality, Windows malware is very rarely signed (literally only in single cases) because it provides a traceable link to the developer.
Implementing UEFI Secure Boot in Fedora Posted Jun 3, 2012 2:56 UTC (Sun) by hummassa (subscriber, #307) [Link]
One word: bollocks.
Better, another word: Stuxnet.
> , Duqu and Flame are not normal, everyday malware, of course. All three of them were most likely developed by a Western intelligence agency as part of covert operations that weren’t meant to be discovered. The fact that the malware evaded detection proves how well the attackers did their job. In the case of Stuxnet and DuQu, they used digitally signed components to make their malware appear to be trustworthy applications. And instead of trying to protect their code with custom packers and obfuscation engines—which might have drawn suspicion to them—they hid in plain sight. In the case of Flame, the attackers used SQLite, SSH, SSL and LUA libraries that made the code look more like a business database system than a piece of malware.
Read it at http://arstechnica.com/security/2012/06/why-antivirus-com...
Implementing UEFI Secure Boot in Fedora Posted Jun 3, 2012 13:30 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
Yeah, Stuxnet is an exception. So?
Most of malware is still unsigned (and that's not likely to change).
Implementing UEFI Secure Boot in Fedora Posted Jun 4, 2012 0:13 UTC (Mon) by hummassa (subscriber, #307) [Link]
Your overtly wrong point is that it's not likely to change. There is no *need* for a lot of signed malware today. If, in the future, malware had to be signed to run, then it *will* be signed.
What is not likely to change is that malware will exist and will infect a lot of our computers just like it does today. And cryptographically signing code does absolutely nothing to stop that. Why? Because if every software have to be signed to run, all malware will get signed. Even if the OS refuse to run a single non-signed bit of code, malware will still exist. The stuxnet & friends example I gave were a cautionary tale. There is malware in a lot of signed-only software platforms.
The only thing signed-only platforms bring to the software world is that it turns much more easy to get a scapegoat. No fool will sign malware with his own signature, but it's always good to steal your bosses and coworkers' private keys, you know, just in case...
Implementing UEFI Secure Boot in Fedora Posted Jun 4, 2012 4:20 UTC (Mon) by dilinger (subscriber, #2867) [Link]
Implementing UEFI Secure Boot in Fedora Posted Jun 4, 2012 5:13 UTC (Mon) by raven667 (subscriber, #5198) [Link]
Turns out secure boot is probably not secure against Uncle Sam. The real world is looking more like the world of Brazil every day.
Implementing UEFI Secure Boot in Fedora Posted Jun 4, 2012 14:34 UTC (Mon) by hummassa (subscriber, #307) [Link]
> Turns out secure boot is probably not secure against Uncle Sam.
Let me enforce this once again:
So-called "secure" boot is not secure at all.
So-called "secure" boot means ATPM "booting only cryptographically signed binaries". But for any general-purpose computation device be remotely useful, it has to have variable input and output, IOW: somewhere there will be a bug lurking and enabling some sort of exploit by clever manipulation of said IO. Booting only signed binaries does not enhance the security. You don't need Uncle Sam powers to jailbreak iPhones and iPads. At one moment (I assure it, this is still possible) I jailbroke my iPad just by acessing a cleverly-design website. I. e., no need for physical access, if the jailbreak developer was a malware developer, they could have sent a lot of "Caroline Dieckmann nude pics" links via e-mail, twitter and facebook and pwned a lot of iPads and iPhones all around.
So-called "secure" boot means if a key is appropriated by a malware developer, you have a patsy to say "hey, that is Jon's key! Fire him! Sue him!" and CYA.
There is no way -- and there will never be any way, without limiting deeply what computers can do -- to guarantee that all software you have in a computing device is what you think it is and does only what you think it does.
Implementing UEFI Secure Boot in Fedora Posted Jun 4, 2012 19:00 UTC (Mon) by raven667 (subscriber, #5198) [Link]
I'm not sure how security is implemented in iOS and whether or not it is directly comparable to this scheme. UEFI secure boot only validates the bootloader, everything beyond that is going to be OS specific and out of scope of UEFI. Other systems have implemented this kind of cryptographically protected security, such as the Sony PS3, and have been very resilient in the face of persistant attack. AFAIK the PS3 has only had one successful attack in 5+ years, and that wasn't able to persist on the system, the secure update mechanism remained intact and was able to clean off the exploit and prevent re-exploitation. I would hope that our rockstar Linux devs could build a system at least as resistant to attack as that, if not more so.
Implementing UEFI Secure Boot in Fedora Posted Jun 4, 2012 19:21 UTC (Mon) by hummassa (subscriber, #307) [Link]
> I'm not sure how security is implemented in iOS and whether or not it is directly comparable to this scheme. UEFI secure boot only validates the bootloader, everything beyond that is going to be OS specific and out of scope of UEFI.
That is *exactly* how iOS boot security works. It only loads cryptographically-signed OS images. I. e., except when it's exploited and then it does not.
> Other systems have implemented this kind of cryptographically protected security, such as the Sony PS3, and have been very resilient in the face of persistant attack. AFAIK the PS3 has only had one successful attack in 5+ years, and that wasn't able to persist on the system, the secure update mechanism remained intact and was able to clean off the exploit and prevent re-exploitation. I would hope that our rockstar Linux devs could build a system at least as resistant to attack as that, if not more so.
Nobody told that to my (still using Linux) PS3.
I repeated over and over, I really don't think that writing a general-purpose OS and computer that resists to attacks and that not would run *any* unsigned code in the time-frame of two years or more is a possible goal.
The timeframe for iDevices jailbreak is usually at most two months after a new version of the bootloader is out (the developers usually keep some of the vulnerabilities on the bootloader secret so when Apple plugs a hole, they have another to exploit). This is exactly what will happen in the case of OS-locked general-purpose computers, if they are as popular as iDevices...
Implementing UEFI Secure Boot in Fedora Posted Jun 4, 2012 19:49 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
Until you run out of bugs.
Boot protection on iDevices is half-hearted at best. Apple doesn't really care about you jailbreaking their hardware.
Now, try to jailbreak XBox360 hypervisor - it's impossible or very close to it.
Implementing UEFI Secure Boot in Fedora Posted Jun 4, 2012 20:13 UTC (Mon) by raven667 (subscriber, #5198) [Link]
> That is *exactly* how iOS boot security works. It only loads cryptographically-signed OS images. I. e., except when it's exploited and then it does not
I don't think either of us have enough details to speak intelligently on the subject of iOS boot security, the details matter.
> Nobody told that to my (still using Linux) PS3.
So you are both running Linux and recent games, PSN, etc. or did you just stop updating your machine?
|
|||||||||||||