| |||||||||||||
Garrett: Secure Boot and Restricted BootGarrett: Secure Boot and Restricted BootPosted Apr 7, 2013 20:35 UTC (Sun) by paulj (subscriber, #341)In reply to: Garrett: Secure Boot and Restricted Boot by mjg59 Parent article: Garrett: Secure Boot and Restricted Boot
raven667 also gave the "security isn't binary" argument before, my response to that is at: http://lwn.net/Articles/545877/
The problem with your example is that you have the pre-requisites the wrong way around. A more secure/controlled user-space, which technologies like SELinux try to give, is the *pre-requisite for Secure Boot*. Further, Secure Boot *also* requires a secure kernel, at least one a lot more secure than we have today. We are a *long* way from having this.
Now, once you have secured kernel and user-space to the point you can have some confidence that all software that is guaranteed to run (e.g. start-up) is unlikely to be subverted by the class of attacker you're worried about, then here's the funny thing: You don't need Secure Boot anymore!
The amazing thing about Secure Boot is that for it to worth anything to the owner, it requires the very thing that would render it moot.
However, Secure Boot is still worth something to others - it gets "Restricted Boot \ 1 flag" implemented, deployed and supported by Windows and all the major PC OSes. When that is done, then if someone flips that bit, there will be no Linux vendor left who can say "that breaks our boot".
(Log in to post comments)
Garrett: Secure Boot and Restricted Boot Posted Apr 7, 2013 20:45 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
And selinux would be unnecessary if userspace were already secure, so it's also pointless?
Garrett: Secure Boot and Restricted Boot Posted Apr 7, 2013 22:33 UTC (Sun) by hummassa (subscriber, #307) [Link]
The problem here is that our argument is: deep "secure" boot support collaborates with future restriction of boot. SElinux, OTOH, does no such thing.
You can see another difference in nomenclature: one pretends to be "secure", the other explicitly states that it is "security-enhanced". Who is blatantly lying to the consumer? :-D
Garrett: Secure Boot and Restricted Boot Posted Apr 7, 2013 22:40 UTC (Sun) by mjg59 (subscriber, #23239) [Link]
So it adds security, you just worry that it can be used for evil? That's not what you said earlier.
Garrett: Secure Boot and Restricted Boot Posted Apr 8, 2013 5:08 UTC (Mon) by paulj (subscriber, #341) [Link]
SELinux allows the admin to control how running software interacts, including software not critical to startup, and software that interacts with the outside world, and software that dumb/malicious users might run (inc. software they load into the box). It can restrict what compromised software can do. It brings tangible benefits to securing user-space, particularly for network facing software, despite its complexity.
Security in context: What does Secure Boot add against the type of attackers sophisticated enough to subvert the kernel and modify boot? Why _aren't_ these attackers also capable of just subverting the boot, again and again?
There's a whole class of software, and methods of attacking it, that have traditionally been viewed as "not security-sensitive", which suddenly become *front-line* once you have Secure Boot, from /etc config files, to state in /var, to kernel modules, to on-disk fs data structures (h/t Al). If those fail, then there'll still be a wealth of data read by non-privileged programmes from which to get started up and then run a kernel exploit.
The Google Chrome security bounties have demonstrated that we over-estimate the benefits of just adding additional hoops, and that the X-hats are incredibly capable at stringing together exploits of long chains of bugs into attacks.
Garrett: Secure Boot and Restricted Boot Posted Apr 7, 2013 21:51 UTC (Sun) by kleptog (subscriber, #1183) [Link]
Secure Boot doesn't require a secure kernel. Let's assume the kernel is insecure, a reasonably valid assumption as you point out.
Case 1: Malware uses a vulnerability in the kernel to join a botnet and hide itself from userspace. This is out of scope for secure boot so not relevant.
Case 2: Malware uses a vulnerability in the kernel to modify the boot sector so it gets run the next time the computer starts up. The next boot the firmware checks the boot sector and complains to the user that there's an unverified boot sector and that the user should use a boot CD to clean it. Secure Boot achieves it's goal because it's impossible for the malware to install a boot sector that passes the test.
Now you can say that the malware will just install itself into /etc/rc.d/ instead and you'd be right. That's just because no-one has written the code to do any verification on that directory, not because it's not possible. Those tests would be effective at preventing the malware running on boot *even if the kernel was insecure*.
The only thing Microsoft (really Verisign) requires before signing a bootloader is that it can't be used by malware to subvert the windows boot process so it can pass the boot sector test. But this is a social problem which can't be solved by technical means. That's why a bootloader which says "Hi! You're booting MyBootLoader. If this is not what you're expecting contact technical support. Press any key to continue." would probably get signed since it won't allow malware to hide itself.
Garrett: Secure Boot and Restricted Boot Posted Apr 7, 2013 22:44 UTC (Sun) by viro (subscriber, #7872) [Link]
Bullshit. Suppose the kernel hole in question is in e.g. parsing on-disk metadata. You are going to mount root fs, right? And all the "let's make sure /etc/rc.d/ isn't modified" crap in the world is not going to do anything about that, since no visible files need to be modified.
And before you go into "oh, but that reduces attack surface" - not really. Consider a combination of (1) hole in some piece of shit desktop software that goes through luser's homedir and cross-references his pr0n stash^W^Wphoto collection with (2) kernel exploit of any kind used by the code hidden in said collection and executed by (1). Sure, it'll wait until the luser logs in. BFD.
Once a box had been had, it's been had, period.
Garrett: Secure Boot and Restricted Boot Posted Apr 8, 2013 2:10 UTC (Mon) by raven667 (subscriber, #5198) [Link]
That sounds like a nasty scenario but I don't think any general security technology can fix that but even in this case you could safely download an updated kernel and the most your fully owned system could do is block the update, it couldn't modify it.
Garrett: Secure Boot and Restricted Boot Posted Apr 8, 2013 18:09 UTC (Mon) by kleptog (subscriber, #1183) [Link] Sure, it'll wait until the luser logs in. BFD.Actually, I find this a BFD. It means the virus scanner started at boot has a chance to download new signatures and scan for the malware before it has a chance to run. That's a significant improvement over the current situation.
Garrett: Secure Boot and Restricted Boot Posted Apr 8, 2013 20:26 UTC (Mon) by viro (subscriber, #7872) [Link]
In which respect? That Scamantec and their ilk get money from more suckers? I had a front-seat view of some of their games and I'd trust a politician sooner than those shits. If you rely on their products, you deserve everything you get - stupidity must be punished, after all...
Garrett: Secure Boot and Restricted Boot Posted Apr 8, 2013 22:37 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
So when is Linux going to be completely exploit-free with rigidly defined security sandboxes isolating applications' data?
What? You say "never"?
|
|||||||||||||