User: Password:
|
|
Subscribe / Log in / New account

UEFI secure boot kernel restrictions

UEFI secure boot kernel restrictions

Posted Nov 8, 2012 15:22 UTC (Thu) by mjg59 (subscriber, #23239)
In reply to: UEFI secure boot kernel restrictions by raven667
Parent article: UEFI secure boot kernel restrictions

If you're not worried about the kernel being modified at runtime, why are you worried about whether the on-disk copy is verified?


(Log in to post comments)

UEFI secure boot kernel restrictions

Posted Nov 8, 2012 16:25 UTC (Thu) by raven667 (subscriber, #5198) [Link]

Verifying the on-disk copy allows one to cold boot into a known good state, without re-imaging their machine from read-only media, at least until the point where arbitrary, user-supplied code can be run, then you are boned again. You can also safely update the trusted base even on a compromised system, knowing that it hasn't been modified in transit, closing extant holes. You can't prevent the kernel from having holes though so you have no protections after you exit your trusted base, the best you can do is have some scanning as part of your trusted, verified base and run it early enough to catch known malware. This does nothing for zero-day exploits and new malware though.

This is a problem with no easy answers and might not even be a solvable problem given the complexity needed for modern systems. Have you ever read Verner Vinge "Deepness in the Sky"?

UEFI secure boot kernel restrictions

Posted Nov 8, 2012 16:33 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

The point where arbitrary, user-supplied code can be run is the moment you transition into the initramfs - ie, before you can do anything with your known-good kernel. There's zero benefit in verifying the kernel if you're going to permit arbitrary userspace code to rewrite it.

UEFI secure boot kernel restrictions

Posted Nov 8, 2012 16:56 UTC (Thu) by raven667 (subscriber, #5198) [Link]

That's a good point, there is no benefit if the rootkit runs in the initramfs. The only way I can see to solve that is to make the initramfs only run validated, signed code and not arbitrary code.

UEFI secure boot kernel restrictions

Posted Nov 8, 2012 23:26 UTC (Thu) by hummassa (subscriber, #307) [Link]

And *that* is the *impossible* proposition, because to do anything useful the initramfs has to has *some* vulnerability. And *that* is what I have been saying all along: secure boot is only a market-locking weapon and NOT AT ALL secure or security-oriented.

UEFI secure boot kernel restrictions

Posted Nov 9, 2012 18:41 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

> And *that* is the *impossible* proposition, because to do anything useful the initramfs has to has *some* vulnerability.

I'd like a clarification here: initramfs has to have a vulnerability because of:

- what it does; or
- it does so much that *something* it calls is ~100% likely to have *some* vulnerability; or
- something else?

This seems like an important distinction to me, but I'm also unfamiliar with what initramfs actually does or needs to do at a detailed level.

UEFI secure boot kernel restrictions

Posted Nov 10, 2012 1:34 UTC (Sat) by hummassa (subscriber, #307) [Link]

> - it does so much that *something* it calls is ~100% likely to have *some* vulnerability; or

that's the one :-D

UEFI secure boot kernel restrictions

Posted Nov 10, 2012 2:04 UTC (Sat) by raven667 (subscriber, #5198) [Link]

Well you have to presume the kernel has some vulnerabilities but you can control what code calls into the kernel, at least for very early boot when the system is still being set up. Anything that has a fixed function can get signatures and be solidified, the problems come in when you have to run arbitrary code which is outside the users ability to audit.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds