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.
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?