Linus Torvalds on security
article.gmane.org
article.gmane.org
Look, there are two ways to read this comment from Linus.
On the one hand, there's the batshit crazy read, which sincerely believes that data theft, fraud, and privacy violations are on equal footing with performance, reliability, or even data corruption problems. The difference between security flaws and bugs is that bugs don't have adversaries behind them.
But all that really tells us is that Linus has never talked to anybody who worked for a bank.
On the other hand, there's the weary pragmatist's read, which understands what 15 years of withering pompousness from security experts takes out of a development team. These are people who not only want their bugs at the front of the line, but have talking points for Linus to adhere to at the same time.
It's refreshing to see him tell my industry to fuck off. We deserve it.
T'so has the final, true, correct read on this. It's not Linus' job to manage Linux security. There are hundreds of people better situated to do that job. If you don't want Linus spilling the beans on your press release advisory, don't let Linus find out about it. Problem solved.
In fact, Linus has specifically said in the past that he does not want to be told about security issues. If you find a security issue in the linux kernel, report it to vendor-sec.
Responsible disclosure, i.e., making sure that fixes are ready before an issue is announced, requires vendor coordination. The politics is unavoidable if you want to do things right -- although, speaking as someone who is on vendor-sec, the politics really is rather minimal these days.
Linus isn't saying "don't tell me about your security problems".
I didn't claim that he was saying that today. I said that in the past he has said that.
Vendor "coordination" of security flaws often works to the detriment of users. For one thing, cliques like vendor-sec gossip and share findings with the "cool kids", ensuring that every interested party but the operators knows what's coming a week before the advisories are published. For another, it substitutes the judgement of people like you --- who, no offense, don't run real world systems or make real world risk assessments about real assets --- for the judgement of the people who are not like you, but who could potentially disable or work around vulnerable systems far in advance of "coordinated patches".
PS: "I said in the past, not today!" --- if you believe in what you're saying, say it and then defend it with evidence. But don't slam competing projects just because you think nobody's going to call you on it, Colin.
Especially considering what he said regarding the vendor-sec -
I refuse to have anything to even _do_ with organizations
like vendor-sec that I think is a corrupt cluster-fuck of
people who just want to cover their own ass.
Then I started writing my own software. I try to write things securely as possible (security is usually == to correctness, which I always want), but if I miss something, I don't really care. If you are using my code, you should read it and make sure I didn't fuck up something stupid. If you are a "security researcher", I definitely want your patches... but if you are going to call me names for writing free software that you find useful... I just don't care. Sure, the bug will be fixed... but security bugs are just like any other bugs. All bugs need to be fixed. To do that, you need to send a patch.
So I get exactly what Linus is saying here. If you want to be respected in the open source community, write code, and patch existing code. Everyone has egos, but ignore don't let that distract you from what matters -- code. (Hey, I even have a tshirt that says "Code Matters" on it, so it must be true!)
He has a very valid point: all the boring normal bugs are _way_ more important.
Security bugs are just a special case of normal bugs, a test condition unaddressed.
My point is to broaden the notion of security, not to attenuate concern over remote attacks.
There is also a CS-theoretic difference between "all the boring normal bugs" that emerge during variations of normal use cases, and the much larger, much harder to model class of byzantine failures that occur only when components of the system are forced to operate at odds with the the system as a whole. Security failures are byzantine failures. They are, at the very least, extremely difficult to predict and plan for.
The valid point I think Linus is getting at (perhaps I'm reading too much into it) is that if you solve normal, boring bugs, you prevent the much trumpeted security bugs from ever coming out. By heaping praise on the security team and ignoring the careful programmer who writes good code and eliminates bugs before they exist, Linus sees the community move towards a crisis-solving mode rather than a crisis-prevention mode. His view is that it's far better to focus on writing good, solid code that tests robustly rather than hyper-focusing on security at the cost of everything else. This is not to dismiss the importance of security; instead, it is a fundamental focus shift -- thus the example of OpenBSD, where Linus sees security paranoia has subsumed everything else.
It's OpenBSD's approach --- and they pioneered it --- that "all bugs are eventually exploitable". That dogma, which some people say has served them well, contributes to the impression that OpenBSD is (1) fascistic about technical matters that at first glance seem more about vanity than about security, and (2) hypocritical in the extreme about what actually happens in their codebase.
What Linus is saying really doesn't have anything to do with security. What he's saying is, "my job is to improve Linux, and if you give me a valid bugfix, I will treat it the same way I treat any other important bug".
I read too much into Linus's words.
But in Linus' defense, it's not like the Linux platform has ever benefited from anything OpenBSD did. Like OpenSSH, which the OpenBSD team developed and pretty much every Linux distribution takes advantage of...
OpenBSD mindset is to achieve security through excellence. Everyone can look at their code and perceive its quality: everything follows the same coding guidelines, it's well commented and easy to understand, every important commit in the CVS has to be reviewed by at least another commiter, errors are handled early... after looking at it, Linux looks a mess.
That obsession about security leads to a software product that shows robustness and quality. Yes, Linux outperforms OpenBSD in many areas, it has been ported to more architectures and has more functionalities. But, still, Linux could learn a lot about OpenBSD as a project.
There is indeed a lot Linux can learn from OpenBSD, but imitation is probably not the right way to go about it.
OpenBSD's track record on security is not unblemished.
no one's security record is unblemished and i don't think anyone from the openbsd project would say it is.
I had problems with OpenBSD's UVM too, but it was a known issue and increasing NKMEMPAGES_MAX solved it.
Security for linux to me is what the desktop is to the Internet. Sure it's important but hardly relevant where OS security is a hosting task. I'm surprised Linus is really reported as much as in the past. The time of worring about the single machine OS kernel while interesting is simply not relevent in the new era of Internet OS.
The beauty of not being paid for what you do is the luxury of being able not to bother with bullshit.
And yes, security is overrated. All major "security" problems have always been DOS attacks that have NOTHING to do with "breaking" into anything. The biggest problem with computer "security" is the widespread adoption of "anti-virus" softwares. That plague does more harm than viruses themselves.
Last graf, first thr---two sentences: crazy talk.
Last graf, last 2 sentences: dead on. Amen.
(Do you think soldiers, chefs, car salespeople, and senators talk especially differently, when they're not in the limelight?)
If anything, this little statement has entirely too few four-letter words to be a really believeable engineer rant.
Of course, if you want to see someone as immature it always helps to rip a single statement entirely out of its conversational context. I frankly have no idea whether Torvalds is being sensible or stupid, brilliant or childish here. It depends on who is asking what.
(I liked it.)