
Linus Torvalds on security - alex_c
http://article.gmane.org/gmane.linux.kernel/706950
======
tptacek
The fundamental dispute here is that security researchers want Linus to take a
vow of silence on any bug they report to him, which vow extends all the way
into how Linus manages the git repositories.

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.

~~~
cperciva
_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.

~~~
tptacek
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.

~~~
cperciva
_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.

~~~
tptacek
"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.

------
jrockway
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!)

------
biohacker42
I am sure Theo will have a subdued, low-key response.

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

~~~
tptacek
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.

~~~
dominik
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.

~~~
tptacek
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".

~~~
dominik
Ah, thanks for the clarification.

I read too much into Linus's words.

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

~~~
tptacek
It's too bad, because we'd benefit from another well-maintained implementation
of SSH. OpenSSH has had its problems.

~~~
there
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.

~~~
tptacek
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.

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

~~~
tptacek
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
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.

~~~
tptacek
The code in question was the virtual memory system. That's what UVM is.

------
bootload
_"... 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.

------
sophist
Is it a job requirement for tech super geeks to have the maturity of a high-
school kid?

~~~
tx
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.

~~~
tptacek
First two grafs: dead on. Amen.

Last graf, first thr---two sentences: crazy talk.

Last graf, last 2 sentences: dead on. Amen.

~~~
nuclear_eclipse
I count only four sentences in his last paragraph...

------
lst
If some explodes so rarely (like him), at least he has to do it special!

(I liked it.)

