Not logged in
Log in now
Create an account
Subscribe to LWN
Pencil, Pencil, and Pencil
Dividing the Linux desktop
LWN.net Weekly Edition for June 13, 2013
A report from pgCon 2013
Little things that matter in language design
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)
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.
Posted Jun 1, 2012 20:49 UTC (Fri) by gmaxwell (subscriber, #30048)
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.
Posted Jun 1, 2012 21:37 UTC (Fri) by nybble41 (subscriber, #55106)
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.
Posted Jun 2, 2012 6:54 UTC (Sat) by dilinger (subscriber, #2867)
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.
Posted Jun 4, 2012 4:43 UTC (Mon) by raven667 (subscriber, #5198)
Posted Jun 2, 2012 3:48 UTC (Sat) by raven667 (subscriber, #5198)
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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds