4 ms·

Aye, too many people have this defeatist attitude that since perfect security will never be possible, therefore the only valid solution is reactive security (bu

Aye, too many people have this defeatist attitude that since perfect security will never be possible, therefore the only valid solution is reactive security (bug-patch cycles). Patch dependence is considered too entrenched for making some changes like replacing ambient authority with capabilities, using failure-oblivious computing [1] to redirect invalid reads and writes, using separation kernels, information flow control, proper MLS [2], program shepherding for origin and control flow monitoring [3] and general fault tolerance/self-healing [4]. I used to look up to Linus Torvalds as many did, but am increasingly beginning to see him as a threat to the advancement of the industry with his faux pragmatism that has led him to speak out against everything from security to microkernels and kernel debuggers. [1] https://www.doc.ic.ac.uk/~cristic/papers/fo-osdi-04.pdf https://www.doc.ic.ac.uk/~cristic/papers/fo-osdi-04.pdf [2] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.52.366&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.52.... [3] https://www.usenix.org/legacy/events/sec02/full_papers/kiriansky/kiriansky.pdf https://www.usenix.org/legacy/events/sec02/full_papers/kiria... [4] https://www.cs.columbia.edu/~angelos/Papers/2007/mmm-acns-self.pdf https://www.cs.columbia.edu/~angelos/Papers/2007/mmm-acns-se...

jpgvm 11y ago
I wouldn't be so harsh. Linus thinks and works in the here and now. He is neither interested in the theoretical or bothered by what theoretical people have to say about him. He ships code that works and works well and generally speaking has a good security track record compared to many userspace systems (Adobe Flash anyone?). At the time he was against microkernels it would be fair to say monolithic kernels did definitely have (and continue to have) performance advantages over microkernel architectures. Have things changed? Somewhat. Some of how OS kernels are used has changed and that has made microkernels more attractive again. I feel the rest of your argument just feels like the jab at Linus is tacked on though because he doesn't seem to be against capabilties system. (infact the kernel has what? 3 capabilities systems?) Nor does he seem against forms of multi-level security or program shepherding. So maybe those weren't meant to be directed at him. Either way I just wanted to say that people should give him some slack, his job isn't to please security zealots but to ship software all of us use and many of us depend on for our livelihood in a timely and reliable manner.
- vezzy-fnord 11y ago
  At the time he was against microkernels, QNX had already demonstrated they were faster than the monolithic state of the art. [1] Linux does not have any form of capabilities (maybe Capsicum, but it's not finished). Capabilities are not POSIX capabilities, which redefined a decade-old term, but rather this [2]. The rest is just trite dismissals of the same faux pragmatism that Linus embodies. He's "not interested in the theoretical", as if there is any other? Before the now-mundane ideas became the staples of pragmatists, they were theories hidden in the research literature. Linus is a major figurehead and his promoting of self-destructive attitudes is undesirable. In fact, you claim he lives in the here and now. He does not. The here and now has long surpassed him and he now lives in his own realm. [1] https://cseweb.ucsd.edu/~voelker/cse221/papers/qnx-paper92.pdf https://cseweb.ucsd.edu/~voelker/cse221/papers/qnx-paper92.p... [2] http://www.eros-os.org/essays/capintro.html http://www.eros-os.org/essays/capintro.html
  - armitron 11y ago
    I didn't really refer to his massive ego in my previous comment, but this is another facet of his idiocy in my opinion. The signs were there 20 years ago, but now one could say that the adorations and worship of vast number of subordinates and minions have all turned him into a monster, like a caricature of the corrupt Roman emperors. I sure hope some other leading figure emerges and seizes some control over Linux because I sure don't see Linus changing the way he does business.
    - antocv 11y ago
      My vote goes to Spender.
- armitron 11y ago
  No, nobody should give Linus any slack whatsoever. He's responsible for the current fiasco, where stock Linux kernel is a joke security-wise, one can find reliable vulnerabilities in a few hours, once the debugging infrastructure is there. Compare that with Windows where it's a few weeks to a few months and then a lot more work to get the reliability. Linus holds the vast majority of the blame here, simply put, he is an idiot when it comes to security or looking ahead at how things will be in a couple of years. Linux is slowly entering every single aspect of our lives and this trend will only accelerate via IoT. Imagine what this means about security with Linus in charge. We now KNOW that there are intelligent adversaries out there that spend hundreds of millions to defeat security worldwide. It is simply UNACCEPTABLE and downright MALICIOUS STUPIDITY for Linus to hold the views he does in this day and age. He's been repeatedly warned and cautioned for more than a DECADE now and he's laughed at and ignored valid criticisms from people with much more foresight than him. If this trend continues, he should be NAILED to the cross. A security bug is NOT just a bug. No, I shouldn't have to DISCONNECT everything that runs Linux from the Internet if I want it to have a modicum of security.
infinity0 11y ago
> perfect security will never be possible, therefore the only valid solution is reactive security Yes, I've heard this implied before. This is effectively doing the adversary's work for them, and for free! Perfect truth is never attainable, therefore let's not do science? To put it in more positive terms, achieving perfection is not important. What is important is a continual methodical process to keep improving, that more-than-offsets natural tendencies to deteriorate. In software engineering terms, it means not letting the project grow to a state where the exploit-discovery rate is so high. Since exploits generally affect the entire kernel, it's negligent and reckless, to be satisfied with merely keeping the bug-per-SLOC ratio constant.
fulafel 11y ago
The concept you list are orthogonal to most sources of kernel vulnerabilities and most of grsecurity's defenses: C-related exploitable memory safety bugs. grsecurity's C exploitation mitigation tech is just a band-aid for these. Of course a kind of Amdahl's law applies to these: eliminate memory safety related vulnerabilities, capabilities and such become important in eliminating the rest of the bug classes...
- nickpsecurity 11y ago
  Yeah, but you get really far by eliminating memory and control flow attacks. There's also relatively cheap ways to do that with hardware and software. There's even schemes like SAFEcode/SVA, Code Pointer Integrity, and Softbound + CETS that do it automatically with a performance hit many apps can take. Yet, what's uptake of such methods in mainstream, kernel development? There's the problem.
  - fulafel 11y ago
    Or you could just use a memory safe language instead of getting into the C mitigation arms race. Time and time again mitigation techs have gotten widely deployed, exploits have caught up, it's a perpetual cycle. Yes the exploitation gets a little harder each time around, but you don't get sound memory safety that way.
    - nickpsecurity 11y ago
      I agree: my main recommendation for new projects. However, avoiding C or porting Linux/BSD to a safe language fell on deaf ears for decades. So, for them, I recommend techniques that work with C and UNIX architecture. Maybe more progress that way.
grandinj 11y ago
Those are all user space level mitigations so you don't need the kernel to implement them. So you are barking at the wrong group.
- vezzy-fnord 11y ago
  Separation kernels aren't, MLS likely works best with kernel cooperation (given Linux's large surface) and same with capabilities at least. My point wasn't the specific proactive mitigations, but rather Linus' attitudes creating negative perceptions.
- nickpsecurity 11y ago
  Those might be but microkernels, safe languages, interface correctness (pre/post-condition checks), and safe coordination schemes aren't: built from kernel up and proven since 70-80's to prevent/contain many issues that affect C-based monoliths like Linux. That they actively argue against using them despite decades of evidence they work says plenty about them. That they also advocate and use methods that haven't worked for decades in terms of predictability/reliability/security is final nail on the coffin. People should keep barking given how much depends on the project now. Plus support alternatives that take better approaches to architecture like old EROS, MINIX 3 (reliability), or GenodeOS (security/reliability). Safe native approaches like security-enhanced Oberon System or JX Operating System would also kick butt. Each achieved certain robustness properties in mere years with small teams due to good design. UNIX and Linux took decades to get usable, still give hackers MB of opportunities for kernel attacks, and still crash my systems on occasion. Meme: "Failure to learn the lessons of the past and apply them."

jpgvm 11y ago

I wouldn't be so harsh. Linus thinks and works in the here and now. He is neither interested in the theoretical or bothered by what theoretical people have to say about him. He ships code that works and works well and generally speaking has a good security track record compared to many userspace systems (Adobe Flash anyone?). At the time he was against microkernels it would be fair to say monolithic kernels did definitely have (and continue to have) performance advantages over microkernel architectures. Have things changed? Somewhat. Some of how OS kernels are used has changed and that has made microkernels more attractive again. I feel the rest of your argument just feels like the jab at Linus is tacked on though because he doesn't seem to be against capabilties system. (infact the kernel has what? 3 capabilities systems?) Nor does he seem against forms of multi-level security or program shepherding. So maybe those weren't meant to be directed at him. Either way I just wanted to say that people should give him some slack, his job isn't to please security zealots but to ship software all of us use and many of us depend on for our livelihood in a timely and reliable manner.

vezzy-fnord 11y ago
At the time he was against microkernels, QNX had already demonstrated they were faster than the monolithic state of the art. [1] Linux does not have any form of capabilities (maybe Capsicum, but it's not finished). Capabilities are not POSIX capabilities, which redefined a decade-old term, but rather this [2]. The rest is just trite dismissals of the same faux pragmatism that Linus embodies. He's "not interested in the theoretical", as if there is any other? Before the now-mundane ideas became the staples of pragmatists, they were theories hidden in the research literature. Linus is a major figurehead and his promoting of self-destructive attitudes is undesirable. In fact, you claim he lives in the here and now. He does not. The here and now has long surpassed him and he now lives in his own realm. [1] https://cseweb.ucsd.edu/~voelker/cse221/papers/qnx-paper92.pdf https://cseweb.ucsd.edu/~voelker/cse221/papers/qnx-paper92.p... [2] http://www.eros-os.org/essays/capintro.html http://www.eros-os.org/essays/capintro.html
- armitron 11y ago
  I didn't really refer to his massive ego in my previous comment, but this is another facet of his idiocy in my opinion. The signs were there 20 years ago, but now one could say that the adorations and worship of vast number of subordinates and minions have all turned him into a monster, like a caricature of the corrupt Roman emperors. I sure hope some other leading figure emerges and seizes some control over Linux because I sure don't see Linus changing the way he does business.
  - antocv 11y ago
    My vote goes to Spender.
armitron 11y ago
No, nobody should give Linus any slack whatsoever. He's responsible for the current fiasco, where stock Linux kernel is a joke security-wise, one can find reliable vulnerabilities in a few hours, once the debugging infrastructure is there. Compare that with Windows where it's a few weeks to a few months and then a lot more work to get the reliability. Linus holds the vast majority of the blame here, simply put, he is an idiot when it comes to security or looking ahead at how things will be in a couple of years. Linux is slowly entering every single aspect of our lives and this trend will only accelerate via IoT. Imagine what this means about security with Linus in charge. We now KNOW that there are intelligent adversaries out there that spend hundreds of millions to defeat security worldwide. It is simply UNACCEPTABLE and downright MALICIOUS STUPIDITY for Linus to hold the views he does in this day and age. He's been repeatedly warned and cautioned for more than a DECADE now and he's laughed at and ignored valid criticisms from people with much more foresight than him. If this trend continues, he should be NAILED to the cross. A security bug is NOT just a bug. No, I shouldn't have to DISCONNECT everything that runs Linux from the Internet if I want it to have a modicum of security.

infinity0 11y ago

> perfect security will never be possible, therefore the only valid solution is reactive security Yes, I've heard this implied before. This is effectively doing the adversary's work for them, and for free! Perfect truth is never attainable, therefore let's not do science? To put it in more positive terms, achieving perfection is not important. What is important is a continual methodical process to keep improving, that more-than-offsets natural tendencies to deteriorate. In software engineering terms, it means not letting the project grow to a state where the exploit-discovery rate is so high. Since exploits generally affect the entire kernel, it's negligent and reckless, to be satisfied with merely keeping the bug-per-SLOC ratio constant.

fulafel 11y ago

The concept you list are orthogonal to most sources of kernel vulnerabilities and most of grsecurity's defenses: C-related exploitable memory safety bugs. grsecurity's C exploitation mitigation tech is just a band-aid for these. Of course a kind of Amdahl's law applies to these: eliminate memory safety related vulnerabilities, capabilities and such become important in eliminating the rest of the bug classes...

nickpsecurity 11y ago
Yeah, but you get really far by eliminating memory and control flow attacks. There's also relatively cheap ways to do that with hardware and software. There's even schemes like SAFEcode/SVA, Code Pointer Integrity, and Softbound + CETS that do it automatically with a performance hit many apps can take. Yet, what's uptake of such methods in mainstream, kernel development? There's the problem.
- fulafel 11y ago
  Or you could just use a memory safe language instead of getting into the C mitigation arms race. Time and time again mitigation techs have gotten widely deployed, exploits have caught up, it's a perpetual cycle. Yes the exploitation gets a little harder each time around, but you don't get sound memory safety that way.
  - nickpsecurity 11y ago
    I agree: my main recommendation for new projects. However, avoiding C or porting Linux/BSD to a safe language fell on deaf ears for decades. So, for them, I recommend techniques that work with C and UNIX architecture. Maybe more progress that way.

grandinj 11y ago

Those are all user space level mitigations so you don't need the kernel to implement them. So you are barking at the wrong group.

vezzy-fnord 11y ago
Separation kernels aren't, MLS likely works best with kernel cooperation (given Linux's large surface) and same with capabilities at least. My point wasn't the specific proactive mitigations, but rather Linus' attitudes creating negative perceptions.
nickpsecurity 11y ago
Those might be but microkernels, safe languages, interface correctness (pre/post-condition checks), and safe coordination schemes aren't: built from kernel up and proven since 70-80's to prevent/contain many issues that affect C-based monoliths like Linux. That they actively argue against using them despite decades of evidence they work says plenty about them. That they also advocate and use methods that haven't worked for decades in terms of predictability/reliability/security is final nail on the coffin. People should keep barking given how much depends on the project now. Plus support alternatives that take better approaches to architecture like old EROS, MINIX 3 (reliability), or GenodeOS (security/reliability). Safe native approaches like security-enhanced Oberon System or JX Operating System would also kick butt. Each achieved certain robustness properties in mere years with small teams due to good design. UNIX and Linux took decades to get usable, still give hackers MB of opportunities for kernel attacks, and still crash my systems on occasion. Meme: "Failure to learn the lessons of the past and apply them."