Yep. To get the most out of it you'll want to take years of effort and go after each vector, making sure that your input is valid, etc. Regardless, fixing these attack vectors is still a worthwhile effort, the kernel team is keen on fixing any bugs which allow you to wrest control away from the kernel, but SecureBoot provides a name to it and a priority order of things to check.
Some of this I'm sure is already done, at least for the more well traveled parts of the kernel, things like filesystem data structrures, disk labels, UUIDs were identified as attack vectors for drive by media insertion a long time ago and so it's harder to find bugs in these areas than it was 5+ years ago.
> engineer a system from scratch
That's just not going to happen any time soon. Maybe in 2030 we can talk about a new from the ground up effort to build a new computing ecosystem but I don't think that's ever going to happen, at least its not foreseeable to me. I wouldn't be surprised to see some direct decedent of Linux still in active use in 2050. The shared ownership of the kernel and the inherent mutability of it means that its far more maintainable than any software project of similar complexity ever created before by a single company.
> ... giving up that general programmability ...
> ... more restricted and less flexible computer ...
I'm not sure what you mean here, SecureBoot only provides for signature checking of the UEFI firmware and bootloader code, nothing more. You can turn it off or load your own keys into it or put in static hashes. In what way does it give up general programmability or make your computer more restricted and less flexible? I would agree if we were talking about a boot locked computer like you see in the mobile phone ecosystem, I understand that the technology for both is the same but the difference in policy is a _fundamental_ difference.
> give you a more Secure computer. However, everyone who suggests this is the case seems to quickly fall back "Well, it's not meant to do X - it just secures the boot" when you try get the details of exactly how it does that. :)
Well you probably get that because you seem to expect much much more from this than what it's capable of giving. Without the tool of SecureBoot it's trivially easy for a rootkit to take over your system to the point that only dedicated offline forensic analysis of the hardware could find it, there is nothing that even tries to prevent this. With SecureBoot you are encoding a policy and trying to keep the malware out of some of the common rocks it hides under and flushed out so that it is more exposed.
> Yay, my compromised system at least booted the right code!
At some point before the kernel is re-exploited the system isn't compromised yet and the kernel is giving you accurate data about what is on the filesystem, etc. For example if you can get to your initrd before the malware is given a chance to run (as there are a limited number of defined ways code can be run before the system is compromised) then you can do your own forensic analysis on the computer and find the malware, or a script can do that for you, before the malware has a chance to hide itself after compromising the kernel.
That may seem a more modest goal than having a Secure Computer, just getting to the initrd before the malware has a chance of re-exploiting the system, but I think that is achievable to get there with 95% confidence. That's a matter of opinion so feel free to disagree 8-). Even better would be able to get to running systemd before the malware can run, forcing the malware to launch using standard code paths where it is highly visible. That may be an impossible dream 8-)
Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds