Linux's Security Through Obscurity

An anonymous reader writes "The age-old full disclosure debate has been raging again, this time in no other place than at the foundations of the open-source flagship GNU/Linux operating system: within the Linux kernel itself. It beggars belief, but even Linux creator, Linus Torvalds, has advocated against the sort of openness on which Linux has thrived, arguing that security fixes to the kernel should be obscured in changelogs, saying 'If it's not a very public security issue already, I don't want a simple "git log + grep" to help find it.' Unfortunately, it's not kernel exploit writers who need to grep the changelog in order to find kernel vulnerabilities. On the contrary, it's downstream distributors who rely on changelog information in order to decide when to patch the kernels of their distributions, in order to keep their users safe."

Comments

Linus does not mean obfuscation

[Novus]

Note that the quote from Linus continues:

That said, I don't _plan_ messages or obfuscate them, so "overflow" might well be part of the message just because it simply describes the fix. So I'm not claiming that the messages can never help somebody pinpoint interesting commits to look at, I'm just also not at all interested in doing so reliably.

He doesn't believe in obfuscating changelogs, just not filling them with security information making it easy to find vulnerable kernels.

Completely out of context

[Anonymous Coward]

The article quote is completely out of context, go read the full thread and see what he really said. His main point is that security bugs are like any other bug. He doesn't see the point in putting code that can trip bugs into the git reports, whether it is a security bug or otherwise.

Two sides to this story

[yerdaddy]

This is a an extremely one-sided presentation of this story. Linus makes some controversial but insightful points about the security obsessed culture in the community. This should not have been a "Linus has gone mad" story. This is a legitimate re-evaluation of how security patches are handled.

Read the thread, make your own decision:
http://thread.gmane.org/gmane.linux.kernel/701694/focus=706950

Re:The idealistic young become the cynical old.

[dch24]

Realistically, this article is light on the quotes of Linus because the article is trying to make a big deal out of Linus' words "I personally consider security bugs to be just 'normal bugs'. I don't cover them up, but I also don't have any reason what-so-ever to think it's a good idea to track them and announce them as something special."

At that point, slashdot and schneier.com are just trolling. Read the whole email I quote above:

We went through this discussion a couple of weeks ago, and I had absolutely zero interest in explaining it again.

I personally don't like embargoes. I don't think they work. That means that I want to fix things asap. But that also means that there is never a time when you can "let people know", except when it's not an issue any more, at which point there is no _point_ in letting people know any more.

So I personally consider security bugs to be just "normal bugs". I don't cover them up, but I also don't have any reason what-so-ever to think it's a good idea to track them and announce them as something special.

So there is no "policy". Nor is it likely to change.

It's a flamebait email thread. Linus has harsh words for BSD. Nobody ever said Linus doesn't do that -- but this is not security through obscurity.

His take on security issues is simply: they're bugs. Deal with it.

Missing the point

[IceCreamGuy]

I think what pageexec (the "antagonist" in the referenced thread) was trying to say was that he feels a lot of the developers don't follow Documentation/SecurityBugs in their commits in a consistent way. He's saying that when people post commits for regular bugs, they include a decent amount of data about what they fixed, but if it's a security bug, people are posting a minimal amount in their commits. Apparently in Documentation/SecurityBugs, it says that full disclosure is the policy, but what he's seeing is less than full disclosure in practice. That is what the thread is actually about, Linus' opinions are ancillary to that point.

He's just saying that it seems to him that what is written as policy for kernel devs is not what they're actually doing, so they should either change the policy or change their commits. If the changelogs don't conform to policy, at some point somewhere downstream devs are going to miss something because the policy doesn't match the practice, and that's what's a security risk.

Torvalds falsely accused of security coverup ..

[rs232]

"so guys (meaning not only Greg but Andrew, Linus, et al.), when will you publicly explain why you're covering up security impact of bugs", pagee...@freemail.hu

"I don't cover them up", Torvalds

"by 'cover up' i meant that even when you know better, you quite consciously do *not* report the security impact of said bugs", pagee...@freemail.hu

"Yes. Because the only place I consider appropriate is the kernel changelogs, and since those get published with the sources, there is no way I can convince myself that it's a good idea to say "Hey script kiddies, try this" unless it's already very public indeed", Torvalds

"one reason I refuse to bother with the whole security circus is that I think it glorifies - and thus encourages - the wrong behavior It makes "heroes" out of security people, as if the people who don't just fix normal bugs aren't as important", Torvalds

"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", Torvalds

http://tinyurl.com/5qyon3
http://groups.google.co.uk/group/fa.linux.kernel/browse_thread/thread/5bdf2e1b8a90142c/abcf79768bb7ce7f?hl=en&lnk=st&q=#abcf79768bb7ce7f