Slashdot Mirror
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."
Linux users typically praise open source software on the basis that vulnerabilities can be found easily and patched by anybody who possesses the knowledge to do so, making open source software more secure. Why should this change now?
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.
And from the second email:
> by 'cover up' i meant that even when you know better, you quite
> consciously do *not* report the security impact of said bugs
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.
Also, someone is not satisfied with an email from Linus Thorwalds and he drags the discussion over here to /. - This certainly will solve the problem...
(Sorry for RTFA, I should know better)
Yeah, he thinks security bugs are just like regular bugs. But he's wrong. Most bugs don't bite most users--- the ones that don't can be ignored. Very few people can ignore security bugs--- they bite everyone. The chance I need a random bugfix is very small; if I don't need it, I don't want it. The chance I want a security bugfix is almost 100%.
In the same thread he also says "So as far as I'm concerned, 'disclosing' is the fixing of the bug. It's the 'look at the source' approach."
I don't see any security by obscurity going on here. He fixes the bug, and tells you in the changelog what the bug was.
What he's NOT doing is announcing in advance how to exploit the bug.
So why are so many people getting agitated about this?
Come play free flash games on Kongregate!
He's right - they're just bugs. Where he isn't right is about OpenBSD - security is a by-product of fixing bugs. They don't just fix the bugs, but when a new class of bug is identified the whole source tree is scanned for that type of bug - both kernel *and* user-land. But then Linux is just a kernel, isn't it?
http://cafepress.com/spankymm - for the Masturbating Monkey in you!
Problem is, it only takes one. If a exploit is developed, it can get passed around among the Bad Guys, even if they don't have the smarts to do it on their own. Look at all the script kiddies. I like to know about security issues, but I prefer that a patch is available before the world is told how to attack my systems.
Why, without your clothes, you're naked, Miss Dudley!
No, there was only one openssh bug around that time, the rest were PAM/linux specific issues. And that one openssh bug had nothing to do with it being more widely adopted, it was just an ordinary "bug found in relatively new software" situation.