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

UEFI secure boot kernel restrictions

UEFI secure boot kernel restrictions

Posted Nov 8, 2012 4:18 UTC (Thu) by raven667 (subscriber, #5198)
Parent article: UEFI secure boot kernel restrictions

I have great respect for mjg59's work and intelligence but I too think that this might be introducing far more restrictions than can be supported and more than the threat model warrants. The only thing that is checked by UEFI is the shim, correct? Therefore that is the only thing that can be blacklisted, if it can be used to silently compromise an OS on boot, the rest is just our own leveraging of the Secure Boot feature for our own use. Secure Boot offers very limited protection on boot, nothing after boot and nothing in a virtualized environment IIUC. It doesn't protect the kernel from being compromised and it's not intended to, it's not intended to prevent a compromised kernel from suspending/hibernating and resuming either.

If one is looking for more general ways to secure a running system then there are probably other better places to look like LSM modules or grsecurity.


(Log in to post comments)

UEFI secure boot kernel restrictions

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

What's the point in securing a bootloader if it will then boot an arbitrary kernel? What's the point in only booting a signed kernel if it's trivial to runtime-patch it to do anything you want?

UEFI secure boot kernel restrictions

Posted Nov 8, 2012 13:52 UTC (Thu) by foom (subscriber, #14868) [Link]

Indeed!

This whole "secure boot" exercise is indeed...pointless. :)

UEFI secure boot kernel restrictions

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

But you aren't booting an arbitrary kernel, a cold boot will get you a verified kernel image and modules off disk. As far as the kernel being modified after boot, that's outside the scope of this protection and annother matter entirely. I've worked in security for much of my career, one of the hardest things is knowing when enough is enough, when adding more protections, restrictions and security is counter productive. I think that's the case here.

If we want to work on other kernel security measures then I don't think it should be in the context of Secure Boot as that has been pushed as far as it will go and will take a few years of operational use to cool down. You can start a new project to help prevent unauthorized entry into the kernel, making kexec do signature checking maybe, but you can't _fundamentally_ prevent code from being loaded into the kernel after users pace is started, there are too many holes for that. The kernel team does their level best to plug holes as fast as they can and that's what we have to rely on for now.

UEFI secure boot kernel restrictions

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

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

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