Linux's Security Through Obscurity 215
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."
The idealistic young become the cynical old. (Score:4, Interesting)
The thing is that while security through obscurity is a fools game it can also hurt your users to publish exact details of the security vulnerabilities you've found in your own product before many of your users have had a chance to patch the problem.
Re:The idealistic young become the cynical old. (Score:5, Funny)
Re:The idealistic young become the cynical old. (Score:5, Informative)
At that point, slashdot and schneier.com are just trolling. Read the whole email [kerneltrap.org] I quote above:
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.
Re:The idealistic young become the cynical old. (Score:5, Insightful)
Re: (Score:2)
It's funny how well that doesn't work for them. I still remember the number of bugs that were suddenly discovered in openSSH right after the Linux distros switched over to it.
Re: (Score:2)
Re:The idealistic young become the cynical old. (Score:5, Interesting)
In both. There were some that were Linux only but quite a few affected OpenBSD as well.
It's not that they didn't do a good job and they clearly did a much better job than the SSH daemon they replaced it's just that the Linux distros adopting it increased it's userbase by a lot and as a side affect increased the the number of people who saw a need to look at the code.
Re:The idealistic young become the cynical old. (Score:5, Insightful)
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.
Re:The idealistic young become the cynical old. (Score:4, Interesting)
Re: (Score:2)
Things are nowhere near as bad as I remember from my distant youth, but it's still the case that one of the biggest sources of bugs is fixes.
I'm in favour of keeping systems up to date - although I can be a bit remiss with my systems at home - but I like to stick to fix packages, especially for the servers at work. I'm only going to apply individiual fixes if they're for a problem which is actually affecting my users, or one which might. Security fixes are chief amongst those, particularly since there are
Why we have distros (Score:2)
Most all the distros offer their preferred patched kernel versions. Usually a distro release will be based on a specific kernel iteration, which will then have any security patches back-ported to it. The distro users have ways to check for security notices - and should, on the whole distro, not just the kernel.
Each distro's kernel team should be tracking all patches to the kernel, for all bugs, since even non-security bugs may crash other packages in the distro. They should know enough to spot the fixes tha
Re:The idealistic young become the cynical old. (Score:4, Informative)
Linus doesn't want "security only" fixes.. because then EVERY SINGLE OLD VERSION becomes a target...immediately!
Which is better to say:
"fixed bug #23456 overflow at line #1234 causing dumaflopper() to return incorrect result"
or
"fixed security hole #23456 -- firefox calling line #1234 with variable name = "wiggle" caused dumaflopper() to skip password check"
It's better to quietly fix the bugs, identify where they are and what you fixed.. we fixed 25 overflow errors today -- but don't tell which ones tie to a known security error.. don't make cracker's work too easy.
Many bugs are not "security" problems because nobody has figured out how to break it yet. Just because a bug does not match a security notice does not mean it couldn't be a problem after the patch is released!
Re:The idealistic young become the cynical old. (Score:4, Insightful)
"fixed bug #23456 overflow at line #1234 causing dumaflopper() to return incorrect result - known security problem" or
"fixed bug #23456 overflow at line #1234 causing dumaflopper() to return incorrect result - important update"
would be more appropriate IMO. Letting people know where the security fixes are is important in getting the changes widely distributed.
By hiding it, you're only protecting yourself from second rate hackers. The first rate hackers found the problem and began taking advantage of it well before the development team was aware the problem existed.
Further, a better community understanding and acceptance of insecurity would be an even better idea. Too many people out there think "I've secured this box, I know what I'm doing, nobody can get in" when in fact there are very few such boxes out there and the real security layer being utilized is the fact that there are so many other machines out there that are easier to control. If you know you are vulnerable the mindset changes.
Example: "E-mail has lots of viruses, so I don't open up strange email. Now that I have Norton, it protects me so I open up strange email if it has a subject that draws me in." That's a mindset a lot of people have. Norton gives them the mindset they are secure, but the reality is far from that. If everyone knew how insecure they really were, less people would open up spam or virus-laden spam.
Re: (Score:3, Interesting)
so what happens when the "second rate" hacker finds a way to exploit a bug you didn't rate "security"? Now you've identified bugs, but developers don't check all bugs they catch for security problems, they just fix them. My point is that a bug is a bug, you should patch all of them and run good tests before putting it into production to prove the whole patch works rather than trying to pick and choose parts of the regularly supported patches.
Along the same line, Linus doesn't want to support "security" and
Re:The idealistic young become the cynical old. (Score:5, Insightful)
So, some random - but short, say within 3 days - amount of time later, post a message saying "security fix implemented - please update".
That will alert folks that there's a security issue without spotlighting the problem.
Missing the point (Score:5, Informative)
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.
Re:The idealistic young become the cynical old. (Score:4, Insightful)
Umm.... the schneier article is almost seven years old and discussing apparently discusses a release of the 2.2 kernel. I think the article was referenced purely as summary of security-through-obscurity issues, rather than an attack on Linus.
Re: (Score:2)
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.
Because people always use the newest version of something at all times?
Re: (Score:3, Insightful)
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.
Actually there is a point. Not everybody runs the latest kernel all the time. And so reporting a fixed security problem is not a matter of "we fixed another security problem for you" but rather "all versions of (linux) between 2.6.xx and 2.6.yy are vulnerable to (problem description) and so please upgrade to 2.6.yy+1."
However, Linus' role is to manage the huge volume of changes going into the kernel, and making a big song and dance about security fixes will detract from performing that role. Somebody els
Re:The idealistic young become the cynical old. (Score:5, Insightful)
The thing is that while security through obscurity is a fools game it can also hurt your users to publish exact details of the security vulnerabilities you've found in your own product before many of your users have had a chance to patch the problem.
Surely though, the people who are looking to take advantage of security vulnerabilities, are generally the ones who already have a financial motivation to do so? The people who already have their own dark networks to share or buy and sell vulnerabilities?
Won't they still do this even if it becomes harder to decipher changelogs? The only thing changing then, is that it'll take longer for regular users to see the danger.
There is no absolute security (Score:4, Insightful)
But won't fewer be able to take advantage of security vulnerabilities if it becomes harder to decipher changelogs? Security is not an all-or-nothing situation. The fewer people who know about a vulnerability, the fewer that can exploit it, and that means that users have a lower chance of being exploited.
That's actually an important point about security. You cannot make a useful system without any vulnerabilities. You can only maker it harder to exploit the vulnerabilities, meaning that fewer will be able to exploit them. For example, you cannot make an uncrackable and useful code, but you can make a code so hard to break that very few will even try.
There is no absolute scarcity (Score:2)
Isn't the real problem that you're fighting against market forces which create a demand for the vulnerabilities in the first place?
Re:There is no absolute security (Score:5, Insightful)
Re:There is no absolute security (Score:5, Insightful)
The fewer people who know about a vulnerability, the fewer that can exploit it, and that means that users have a lower chance of being exploited.
Two things to consider:
1) All it takes is one person to exploit your vulnerability. And that one person doesn't even have to know you exist and target you specifically. Most cases involve targets of opportunity.
2) These things don't remain secret. How fast the knowledge is spread only depends on the particulars of the situation. But the knowledge will spread. Sometimes very fast. You're unlikely to be dealing with just one potential attacker.
That's actually an important point about security. You cannot make a useful system without any vulnerabilities. You can only maker it harder to exploit the vulnerabilities, meaning that fewer will be able to exploit them. For example, you cannot make an uncrackable and useful code, but you can make a code so hard to break that very few will even try.
It depends on what kind of vulnerability we're dealing with. There are known trade-offs in the design of a system and then there's failures in the design or implementation.
Security is never absolute by design. There are always trade-offs being made (inverse relationship between usability and security, investment of resources vs. value of what's being protected, etc.). Hopefully designers understand the issues and have made wise choices. But even the most well thought out system will ultimately have left some possibility of subverting it. Thus exists the concept that security is not an absolute.
Bugs and design flaws are a different issue. These are not trade-offs but unintentional mistakes or miscalculations. These are unintentional flaws. It is entirely possible to design or implement a system without flaws. But of course, designing something without flaws or implementing without bugs is difficult.
Re:The idealistic young become the cynical old. (Score:5, Insightful)
Read the replies. Linus is not advocating security through obscurity. He just doesn't want a big flashing sign "SECURITY" on security-related bugfixes. He doesn't want them to stand out in any way at all.
Re:The idealistic young become the cynical old. (Score:5, Insightful)
Re: (Score:3, Interesting)
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%.
And where will the manpower for triaging every bug for possible exploits come from? Not all security-related bugs are easily identifiable as such. And even if they were, and then they were marked as such, do you really want the changelog easily greppable by them?
Re:The idealistic young become the cynical old. (Score:5, Funny)
"Dear God, won't somebody please think of the children?"
Re:The idealistic young become the cynical old. (Score:5, Funny)
"Dear God, won't somebody please think of the children?"
Actually, as a kernel issue, this affects all the system threads.
Re: (Score:2)
first, i guess the reasoning here is to openly mark bugs already known to be security related as such.
second, really, this is about "us" being able to easily understand when we really, really should upgrade the kernel. even if did read full kernel changelogs, i wouldn't be able to understand which commits are security related. so i would rely on somebody to do that AND publicise it, at which point it gets more publicity than simply marking it in the changelog would have provided.
i'd argue that by not making
Re: (Score:2)
even if did read full kernel changelogs, i wouldn't be able to understand which commits are security related. so i would rely on somebody to do that AND publicise it, at which point it gets more publicity than simply marking it in the changelog would have provided.
That's what your distro does. Unless you are rolling your own, in which case, it is up to you to read the entire changelog and understand it.
Re: (Score:2)
this assumes that only large distributions will exist in near future.
imagine that somebody has to read full changelogs for ALL packages (included in the distro)... that's just not realistic and insane.
Re: (Score:3, Interesting)
Don't THEY have the source code, since the kernel is free? How about a simple diff? Seems to me that if a malicious programmer is bothering to grep the changelog, just looking at the code changes isn't THAT much of a stretch? If Linux is "free" as in speech, keep it that way.
Yeah, what (s)he said! (Score:2)
Mod parent insightful!
Re:The idealistic young become the cynical old. (Score:4, Insightful)
Yeah, he thinks security bugs are just like regular bugs. But [I think] he's wrong.
There, fixed it for you. The fact is that just because from your personal point of view a bug that is potentially useful to gain unauthorized rights does not mean that everybody sees it that way.
From what I have read about Linus, he is a very pragmatic guy. For him, a security bug is just another bug in the code (and in a simplistic way, it really is true).
Some people will be more concerned with those bugs, others will be concerned with bugs that reduce the performance of the OS, others will be more interested in bugs that reduce the reliability (as in, crashing every so often, etc).
The fact is that there are lots of people already classifying bugs, I think what Linus is saying is that he does not consider the job of the kernel guys to do such kiind of classification.
For them, it is just another bug that must be seen.
Re: (Score:2)
All bugs bite everyone (unless they're a bug that only happens on certain hardware or software or under certain conditions, of course.)
Security bugs are important, yes, but so are other bugs. So there's a bug that allows a local user to be come root, and there's a bug that will occasionally trash my xfs filesystem. Guess which bug is more important to me to fix? The only case where I might feel differently would be if I ran a general use shell account box, in which case I'd probably be screaming for
Re: (Score:2)
I want a big flashing sign saying "SECURITY" on security related bug-fixes. How else am I going to know that it's important to upgrade?
Most kernel fixes offer me nothing, it's very important that these bug fixes are marked so I know that they're urgent and not to be ignored like most other kernel fixes.
Re:The idealistic young become the cynical old. (Score:5, Insightful)
Congratulations your exactly the reason Linus doesn't want a big flashing "Security" sign.
Linus' point was that most bugs can be potential security problems and if you ignore anything but security fixes you risk not patching in the case of a bug being discovered exploitable after the fix goes into the kernel.
Re: (Score:2, Insightful)
Actually he has a good point in that you don't want to just go blindly patching everything the day the patch comes out. A lot of patches are trivial and fix hardware that has nothing to do with you. This can lead to downtime if the patch causes a new bug.
You can break an otherwise healthy system with a bunch of patches you don't need. By the same token if you don't patch a security issue right away it can lead to system compromise.
Therefore full disclosure of the security issues a patch fixes is necessary.
Re: (Score:3, Interesting)
Wow you have managed to go on a complete rant while ignoring everything I said.
What do you think your CIO will say if you get rooted and your answer is "well there was a bugfix but it wasn't a known vulnerability when the patch came out so I didn't install it"?
Bugfixes are bugfixes and even in the case of security bugs you should be testing before deployment. Don't know if you need to install it? Well just read the freaking changelog and see if it affects a driver or subsystem your using. Even the Paymen
Re:The idealistic young become the cynical old. (Score:5, Insightful)
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?
Re:The idealistic young become the cynical old. (Score:4, Insightful)
What Linus IS doing trolling. Plain and simple.
There is a policy, or at least a strong convention, in place for Linux that bug fix commits should explain in a fairly detailed fashion what was the bug was and/or how it was fixed. However, most of the security fixes are vague and general.
Someone pointed this out, and first Linus said there was no "policy." Someone pointed out that, in fact, there was. Then Linus said that wasn't the point, the issue was that he didn't want script kiddies to be able to find potential exploits easily. So someone pointed out that this means that individuals and distros can't tell whether a given bugfix is urgent or not, and Linus replied that the question whether a bug is related to security or not is difficult to answer. Just to make sure that everyone knew he was trolling hard, he flamed OpenBSD for having a better security record than Linux.
It boggles my mind, the extent to which Linus is able to spew the most outrageous bullshit and Linux nutriders will buy it. He's an excellent programmer and deserving of his reputation, but the cult of hero worship that surrounds him drags down the whole community of Linux users (and by extension, Free Software in general).
What the... (Score:5, Insightful)
Re:What the... (Score:5, Insightful)
Re: (Score:3, Insightful)
It doesn't really matter that the percentage drops. As long as the absolute number of people actually fixing bugs don't drop, the rate of bug fixing will remain constant.
The good thing about "anybody can find and fix the bugs" has never meant "I personally can fix the bugs". It means "somebody out there can fix bugs without having to be part of the developer team".
Re:What the... (Score:5, Insightful)
This has nothing to do with the openness of the source code or the disclosure of vulnerabilities. Linus just doesn't want big proof of concepts for exploits in the last version of the kernel(which there will of course be people still running) to end up in this version. He doesn't want to aid script kiddies. Anyone can still find and patch parts of the code base, there's no move away from that.
Re: (Score:2)
So the openess has affect for security.
New version patched +250 bugs = +250 bugs less
Last version has not patched = +250 bugs open
Those who dont update OS to new version, has those +250 bugs. Those who update the OS to newest version, has +250 bugs less.
Same thing goes for Microsoft Windows NT. +250 bugs closed on next update = those who dont update, has +250 bugs in OS.
What is the difference? Because Linux is open source OS, you can check out what is changed and exploit it if you have skills. Linus does no
Linus does not mean obfuscation (Score:5, Informative)
He doesn't believe in obfuscating changelogs, just not filling them with security information making it easy to find vulnerable kernels.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
How do you know if your kernel has a vulnerability then? If it's passed off as a mere bugfix, you may well decide it's not that important to upgrade your kernel right away.
Re: (Score:2)
A bug that ends up with a computer game character able to jump incredible distances instead of the 'normal' distance doesn't seem like much of a security hole to me. And no, I'm not just talking about Spiderman. A bug is simply anything that causes a program to produce an unintended result, which could be a security exploit, but could just be something perfectly safe, but unexpected (in a bad way, not in a wow-this-AI-is-smart way).
Re: (Score:3, Funny)
Haven't you seen Tron?
Re: (Score:2)
I wasn't really thinking in a kernel context, was just trying to think of an innocent bug. I'm not familiar with the kernel's code so I'm not sure where the kernel ends and other things begin, but if for example there was a bug that meant that the system time consistently read the time of the clock on the mobo as the actual clock time + 1 second, and wrote to the clock as the system time -1 second, then IMO that wouldn't pose a security risk, but I would still consider it a bug of sorts.
'Denial of service'
Re: (Score:2)
Re: (Score:2)
I tried my best - I was actually expecting some smartarse to come up with a way of claiming that a broken toilet was a security risk, perhaps if it meant you had to leave the house to use another toilet, or had to order in some new parts which could be tainted by a man in the middle attack ;)
Re: (Score:3, Interesting)
My theory? Linus is losing his mind, and he slips too far, we will wind up with a fork of the kernel (Ne
Re: (Score:3, Informative)
I agree.
Here's the danger of not identifying security fixes in your patch logs: If a security fix isn't clearly identified, then customers won't necessarily update it.
I run Windows at work, the IT department there has deployed its own WSUS servers. They only deploy security fixes from Microsoft on those servers (don't ask, it's stupid, but it's what they do). If Microsoft were to hide security fixes in non security updates, then our machines would remain vulnerable to those security bugs.
The theory that s
Re: (Score:2)
Here's the danger of not identifying security fixes in your patch logs: If a security fix isn't clearly identified, then customers won't necessarily update it.
How well does this hold if the customers know that fixes don't get special tags for having known security implications? Or when there's an intermediary whose job is specifically to handle such things?
Re: (Score:3, Funny)
I would say that those people are the vulnerability and they're the ones that need patching. Not all vulnerabilities of a system are in the code!
Re: (Score:3, Interesting)
If you want stability just stay on the current branch your on.. ex 2.6.23.x. No new features will be added only bugfixes. Need to know if you need to apply the patch? Just check the change log to see if the bug is in any subsystem you use.
Otherwise you risk someone discovering a bug is exploitable after the patch was added to the kernel.
It's already fixed right? (Score:2, Insightful)
Re: (Score:2)
There is no reason whatsoever to run a non bugfixed kernel. 2.2.x, 2.4.x and every 2.6.x branch since Linus switched over to the new shorter dev cycle are still actively maintained with bugfixes.
Comment removed (Score:5, Insightful)
Re:Isn't that part of their job? (Score:5, Insightful)
Re:Isn't that part of their job? (Score:4, Insightful)
If you don't have the time to perform security maintenance, but someone else does, why shouldn't they be allowed to make a profit for their time?
Re: (Score:2)
Comment removed (Score:4, Insightful)
Re: (Score:2)
Under what conditions would a patch not be worth applying? Thanks to the new shorter dev cycle once a kernel is marked stable it doesn't need or get new features.. only bugfixes.
Re: (Score:2)
Completely out of context (Score:5, Informative)
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.
Re:Completely out of context (Score:4, Insightful)
Agreed. The thing to note is that this cuts both ways.
*Every* bug is a potential security bug. So should we look for ways to try to convert every bug into a security notice? Of course not! Why waste the time? What happens when it turns out that a bug doesn't have security implications? Do we shout "hurray!" and flag it as such?
Linus is entirely correct - a bug is a bug and must be fixed.
Re: (Score:2)
Linus is entirely correct - a bug is a bug and must be fixed.
It's not a bug, it's a feature.
- Bill Gates.
Summary: Flamebait? (Score:5, Insightful)
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)
"Sorry for RTFA"? (Score:5, Funny)
*snort*
And I thought I'd seen every variant on the usual Slashdot in-jokes.
You win a gold star.
So (Score:5, Insightful)
So, what they're saying is when you find/fix a vulnerability you should broadcast on BBC otherwise you will be less safe?
I don't think so. Love it or hate it, obscure security issues do protect some users. Obviously the issues need to tracked and I think changelogs are a good place to do it. There isn't a real reason to inform the world through all channels avaliable. Just fix it, log it, and move on. Anyone who needs to know will know where to look.
Two sides to this story (Score:5, Informative)
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
Masturbating Monkeys (Score:2)
Controversial indeed.... Linus might be mad, but maby of his comments are +5 Funny
I just love the smell of napalm in the morning... (Score:5, Informative)
See the Kerneltrap posting [kerneltrap.org] which includes a good part of the email discussion.
It looks like Linus' main concern is that publicizing a few bugs as "security" issues will act to hide other real security issues that weren't recognized at fix time; that any effort to publicize security issues will be so incomplete as to be misleading. And I see no mention of these concerns in the linked postings, almost as if the "full disclosure" people posting them are afraid to disclose the potential bugs (which would automatically be security bugs because of the topic) in their own methodologies.
Some context. (Score:5, Informative)
From here [seclists.org]
Pragmatism (Score:3, Interesting)
I have never really seen Linus as a prophet, unlike some, and although I can see the sense in being as open as possible - because that gives developers a strong incentive to fix things - I can also see that it may not be completely stupid to allow developers a bit of time to try to fix a newly discovered security vulnerability. I mean, it is not as if we are talking about keeping things very secret in order to avoid doing anything about it; but most of the time, if the news about a problem isn't bellowed out in public as soon as it is discovered, it buys people just a little bit of valuable time.
Not the prophet? (Score:2, Interesting)
Security Through Obscurity does have a benefit (Score:2)
That benefit isn't as great as the benefit of OSS I think...
But consider what could happen if all the software for a voting machine were out in the open. Doubtless there would be those who might find a bug, and keep it to themselves in the hopes of using it to elect who they want. I'm not saying the current situation is better, because I think it's worse, but if the voting software were OS'd we might just be out of the frying pan and into the fire.
IANAP so maybe someone else can offer a technical solution f
Obscurity is an anti-freedom model (Score:2, Insightful)
In the old argument, freedom requires responsibility, this is a prime example of the conflict.
In a truly freedom based model, you assume and rely on the fact that Linux users are responsible for their systems, and thus WARNING SECURITY BUG FIX NOW is a good title to an important patch.
In the less free "sharecropper" future of Linux where user's rely on upstream vendors to "take care of them" and take no responsibility for their systems, hiding such warning is great security theater to make them feel more se
Re: (Score:2)
He's not saying obfuscate security reports, he's just saying he's not going to stick a large flag on the changelog that gets published when the patch does saying SECURITY BUG EXPLOIT ME NOW BEFORE THE SYSADMIN READS THIS!
I understand what you are saying, but it is a disingenuous use of the English language to propose that titles and descriptions be less descriptive so as to not call attention to the real issue, and NOT call that obfuscation.
Re: (Score:2)
If I may make an analogy, it seems like the difference between a flaming campy queer, and an everyday gay guy who doesn't flaunt his sexuality
Neither of which is any less gay. If you intend to change the language in a way to make the real meaning less clear, that is, by definition, obfuscation. You may be arguing relativity, I am arguing an absolute fact.
At what point does Linus start saying, this obfuscation thing isn't working and *ONLY* vetted kernel contributors may see the change logs of unreleased ker
Distributions rely on grep? (Score:2)
Since when did distributions rely on grep to find out about security problems?
There are upstream security mailing lists where security problems are disclosed to the various distributions security teams for most projects (and probably including the Linux kernel), so they probably know about these problems before they are even fixed to begin with.
Wisdom from Ted T'so, as usual. (Score:4, Interesting)
Read this post to get some perspective:
http://article.gmane.org/gmane.linux.kernel/707044 [gmane.org]
Linus is being blunt, as usual, and he's telling everybody what his personal policy is towards disclosure. If he finds a bug, he fixes it, and he doesn't rate security bugs as more or less important than other bugs because he's a kernel hacker, and therefore security bugs are not his sole focus in life. He doesn't use any special language to highlight or obscure security fixes in the changelog, he just describes the fix, which is what people are claiming is "security by obscurity".
From that, people looking for something to bitch about have created this kerfuffle; it is a tale told by an idiot, full of storm and fury, and signifying... nothing.(from Macbeth, 5.5)
"Shakespeare really kicks the cap off" -- James Hovenac
Torvalds falsely accused of security coverup .. (Score:5, Informative)
"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 [tinyurl.com]
http://groups.google.co.uk/group/fa.linux.kernel/browse_thread/thread/5bdf2e1b8a90142c/abcf79768bb7ce7f?hl=en&lnk=st&q=#abcf79768bb7ce7f [google.co.uk]
slashdot indulges in provocative headlines .. (Score:3, Insightful)
Let the evil begin (Score:2)
I knew it couldn't last. Oh well. There is always FreeBSD.
Re: (Score:2)
I knew it couldn't last. Oh well. There is always FreeBSD.
Linus Torvalds, from the very email in question,
...I think the OpenBSD crowd is a bunch of masturbating monkeys...
Shazam! Take that gatkinso!
CmdrTaco indulges in flamebait .. (Score:5, Insightful)
Sponsored by (Score:2)
Having had this (and other similar) conversations follow through LWN.net, LKML and various other places that just won't let me escape it, all I can do is express surprise that the article wasn't "Sponsored by PaXTeam".
Similar arguments keep getting raised by various people affiliated with that name and again and again they just don't listen. It took weeks to get them to bring up such problems in a proper, public forum and now they are just shouting for nothing more than attention.
Nobody cares, because they
Linus is right (Score:2, Informative)
The problem is the bogus presumption that there is a class of bugs called "security bugs", and that fixing these bugs is somehow more important than other bugs.
This, in turn, is based upon the PHB contempt for "hackers", and the assumption that "hackers are always changing things for no good reason"; leading to mechanisms to prevent updates from being installed in the name of "keeping the system stable." Far more harm has been caused by this PHB mindset that has ever been caused by bugs in new code.
When a
Bah! So much polarization (Score:3, Interesting)
Folks, it's not an OMG!!! THEY HID THE BUG AND NOW WE'RE GOING TO DIE!!! issue.
Security through obscurity, for those who remember the olden days, meant not disclosing code, not revealing algorithms, and relying on enforced ignorance on the part of the user/exploiter.
This ain't it. The code is there. The comments are there. Anyone can find it. What Linus is talking about is failing to aid and abet hackers in their attempts. It is simply not ACTIVELY ADVERTISING exploitable code. This is something that seems remarkably sensible.
Unfortunately, anything less "open" than having a courier deliver working exploit code to hackers is labeled "security through obscurity OMFG!!!" by idiots.
Worst article this week (Score:5, Informative)
Most of the controversy is totally misplaced. This is essentially about having
* SECUIRTY ISSUE: fix info
vs.
* fix info
Is that really obscurity?
Re: (Score:3, Funny)
http://thread.gmane.org/gmane.linux.kernel/706950 [gmane.org]
I think the OpenBSD crowd is a bunch of masturbating monkeys, in
that they make such a big deal about concentrating on security to the
point where they pretty much admit that nothing else matters to them.
http://img136.imageshack.us/img136/7451/poster68251050mx9.jpg [imageshack.us]
Re: (Score:3, Informative)
We are not so much looking for security holes, as we are looking for basic software bugs...
Shame Linus has his head stuck up his ass, or he could have read that, too.
Mod parent troll! (Score:2)
It's tolerable that you don't read TFA, but at least read TF comments. The article itself is misquoting Linus.
Otherwise, ask yourself why it takes less than 5 minutes to pwn a Windows computer, but it takes nearly forever to pwn a Linux computer. It's not Linux security that sucks. It's your Redmond-brainwashed mind.