Recent Features
| |||||||||||||
Taking it seriouslyTaking it seriouslyPosted May 31, 2012 14:59 UTC (Thu) by corbet (editor, #1)In reply to: Implementing UEFI Secure Boot in Fedora by sblack Parent article: Implementing UEFI Secure Boot in Fedora 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.
(Log in to post comments)
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.
|
|||||||||||||