Linus Torvalds on security(article.gmane.org)
article.gmane.org
Linus Torvalds on security
http://article.gmane.org/gmane.linux.kernel/706950
10 comments
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.
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.
That's not true. Reporting vulnerabilities to vendor-sec enrolls you in the politics of vendor security, which many reasonable people could make a case for avoiding. Linus isn't saying "don't tell me about your security problems". He's saying "take your talking points and shove them up your ass". On that one single point, he's absolutely right.
Reporting vulnerabilities to vendor-sec enrolls you in the politics of vendor security, which many reasonable people could make a case for avoiding.
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.
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.
"Responsible disclosure" is a marketing term. Linus may be wrong about the importance of security flaws relative to bugs, but that doesn't validate the self-aggrandizing omerta of security researchers.
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.
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.
Hmm .. I have hard time believing that you are not twisting or misinterpreting what he said. Can you source the quote please ?
Especially considering what he said regarding the vendor-sec -
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.
Hooray for context!
I agree with Linus here. My first foray into the world of real software was a computer security class I took in college (taught by DJB, not known for being kind and polite about security problems). Basically, I thought that if I found a minor security problem in some unimportant app, I was God because I was so much smarter than whoever wrote that app. This is the kind of attitude you're encouraged to have by the community.
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!)
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!)
I am sure Theo will have a subdued, low-key response.
I don't think he's exploding at all ('cept for maybe the comments about the OpenBSD crowd).
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.
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.
That's not a very valid point. None of the boring normal bugs cost my mom her credit score or, for the months it takes to resolve the problem, her savings account balance. There has also never ever ever been an X11 bug that took down the Internet.
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.
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.
From what I've seen, most security bugs chain a few normal bugs together. One oversight here, another there, combine them and you have an exploit.
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.
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.
The valid point you're making is not Linus', it's Theo's.
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".
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".
Ah, thanks for the clarification.
I read too much into Linus's words.
I read too much into Linus's words.
Part of the problem is that the term "security" has taken on a very narrow meaning. A bug that crashes a word processor has just as much to do with security as one that allows an escalation of privileges.
Exactly how is it that you figure that a Word'07 crasher is "just as bad" as Word'07 remote code execution? Losing my most important document is still far less damaging to me than losing all my browser cookies, which is what the attacker in the latter scenario wins.
Ya I agree, if you compare the two directly but you have to consider the chance of either event occurring. A highly likely crash that destroys my most important document is more serious to than the much less likely event that an attacker would specifically choose my computer.
My point is to broaden the notion of security, not to attenuate concern over remote attacks.
My point is to broaden the notion of security, not to attenuate concern over remote attacks.
Huge numbers of people have their machines drafted into botnet by drive-by clientside document vulnerabilities like this. Nobody has to choose you as a specific target to make that happen.
Security has it's place. There are certainly gobs of value to having a security focused platform, that benefits even those who view it as a bunch of "masturbating monkeys".
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...
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...
It's too bad, because we'd benefit from another well-maintained implementation of SSH. OpenSSH has had its problems.
i can't wait to see matasano's cross-platform ssh implementation that will be bug free now and forever. let us know when you guys write it.
I don't know where you're reading the "I could do it better" part from. The Internet does have a history of "hard" protocols being deployed almost entirely from a single gene pool: BIND, CMU SNMP, and SSH are three great examples, and two of those three are epic security failures.
I think that Linus is speaking out of his ass this time. Probably looks so arrogant because Theo and him don't like each other and the OSS universe is too small to their egos.
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.
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.
I too have perceived the excellence of OpenBSD. For instance, at Arbor Networks, I had the distinct pleasure of using OpenBSD to manage traffic flows from ISP backbones. When processes malloc'd over 64 megs of data, UVM deadlocked. After writing a passive kernel debugger using KVM to produce repro steps and diag dumps for their team, I was informed that Theo didn't really understand how Cranor's UVM worked, that it was crappy code from Cranor's thesis and all Cranor's fault, and that there was no way I would find anyone who could fix it.
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.
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.
[deleted]
i'm confused what your rant about theo is supposed to mean. you found a problem but didn't know how to fix it, so you presented it to theo and he said he didn't know how to fix it either? he didn't write the code in question and no one on the team (at the time) knew it well enough to change it. what's your point?
no one's security record is unblemished and i don't think anyone from the openbsd project would say it is.
no one's security record is unblemished and i don't think anyone from the openbsd project would say it is.
The code in question was the virtual memory system. That's what UVM is.
Nobody at OpenBSD investigated the issue? Well, that's shocking. Their developers behave as assholes sometimes, but they don't ignore sensible bug reports.
I had problems with OpenBSD's UVM too, but it was a known issue and increasing NKMEMPAGES_MAX solved it.
I had problems with OpenBSD's UVM too, but it was a known issue and increasing NKMEMPAGES_MAX solved it.
Have they matured since then? Maybe so! I was just giving a snarky answer to the assertion that OpenBSD's code was a gleaming gem of righteousness.
"... To me, security is important. But it's no less important than everything 'else' that is also important ..."
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.
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.
Is it a job requirement for tech super geeks to have the maturity of a high-school kid?
That's called "speaking one's own mind" as opposed to corporate doublespeak devoid of any meaningul sense, so common in corporate meeting rooms.
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.
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.
First two grafs: dead on. Amen.
Last graf, first thr---two sentences: crazy talk.
Last graf, last 2 sentences: dead on. Amen.
Last graf, first thr---two sentences: crazy talk.
Last graf, last 2 sentences: dead on. Amen.
It is possible to speak your mind without being crude and callow, actually.
No more so than for any other job.
(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.
(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.
[deleted]
If some explodes so rarely (like him), at least he has to do it special!
(I liked it.)
(I liked it.)
[deleted]
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.