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.
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.
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.
The first systems to be designed for robustness (and have it in practice) were opposite of Linus's approach to doing things. There's some similarities on occasion, which mainly shows talent learned through trial and error. The proven principles for highly reliable and secure OS's aren't applied, though. This is intentional despite massive evidence to the contrary of his position.
Meanwhile, systems like THE (Dijkstra), Burroughs B5500, IBM System/38, GEMSOS (Schell), RC4000 (Hansen), MULTICS, KeyKOS (Bomberger et al), and VAX VMM Security Kernel (Karger/Lipner) showed how to design and implement systems with ultra-high reliability and/or security. These lessons were mostly ignored time and time again even when they could be applied. User-mode drivers and languages with pointer/buffer/stack protection would have by themselves prevented ridiculous amounts of problems. I heard that, after around 2-3 decades, the UNIX crowd is adding some user-mode drivers. See the problem?
Note: Far as lightweight systems & adaptivity, you should see the work of Brinch Hansen, Niklaus Wirth, and Andy Tannenbaum. They applied safe, modular techniques on systems with less resources than today's. UNIX and Linus resist for both personal preference and inertia, not valid technical objections.
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.
I think that your tone will turn a lot of people off, which is why you've been downvoted (by others), but I think that what you said needs to be heard, especially re: IoT. It's a nightmare waiting to happen.
I'm not sure objectively what the current state is. However, it's a little known fact that Linux kernel specifically (due to fame) benefits from tons of academic work on bug hunting tools. Every time they run a new one, they find all kinds of problems that are preventable with a safer language or sound architecture. Many of them would've been contained in a microkernel architecture rather than have full access to memory.
So, one could say it's pretty bad even if the "many eyes" and code audits are finding/fixing a ton. Simply too many to justify if their process is any good. An recent example I found was the Saturn project throwing an automated tool at it and finding 100+ real bugs in one go.
I am unaware of the security warnings etc. against Linus and Linux in general as I am a bit out of touch with Linux, having moved to OSX a few years back.
Do you have recommended reading or links so that I can get up to speed?
Did you read the linked article? Grsecurity people, gentoo security people and other security insiders have been urging Linus and other maintainers to change their views for decades. Nothing has happened except plenty of hand waving and ridicule. Visit the grsecurity forums, the IRC channel for more details.
> 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.
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...
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.
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.
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.
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."
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
[2] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.52....
[3] https://www.usenix.org/legacy/events/sec02/full_papers/kiria...
[4] https://www.cs.columbia.edu/~angelos/Papers/2007/mmm-acns-se...