Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Security Software Linux

Linux's Security Through Obscurity 215

Posted by CmdrTaco
from the we-all-do-it-sometimes dept.
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."
This discussion has been archived. No new comments can be posted.

Linux's Security Through Obscurity

Comments Filter:
  • by HungryHobo (1314109) on Thursday July 17, 2008 @08:36AM (#24227119)
    And so the cycle continues.

    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.
    • by neuromancer23 (1122449) on Thursday July 17, 2008 @08:48AM (#24227283)
      "Get off my lawn!" - Linus Torvalds
      • by dch24 (904899) on Thursday July 17, 2008 @09:09AM (#24227551) Journal
        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. [kerneltrap.org]"

        At that point, slashdot and schneier.com are just trolling. Read the whole email [kerneltrap.org] 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.

        • 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?
        • by frodo from middle ea (602941) on Thursday July 17, 2008 @09:45AM (#24228001) Homepage
          The problem arises when you are using Linux in environments which must meet certain Government (SOX etc) , Industry standard (PCI etc) requirements on security. To meet these requirements you must routinely audit your systems and when you audit your systems, you need to classify security related bugs (vulnerabilities ) found, and having clearly marked security related bugs, will help these auditors/tools do a better job. May be for a kernel developer , security related bugs are on the same level as any other bugs, but for an end user of the Linux system, it will definitely be the most important bug. Otherwise how are Linux vendors supposed to create security-fix only updates ? Or do you expect every one to blindly upgrade the kernel every time a new point release comes out ?
          • by VdG (633317)

            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

            • 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

          • by mabhatter654 (561290) on Thursday July 17, 2008 @11:05AM (#24229187)

            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!

            • by Evets (629327) on Thursday July 17, 2008 @11:50AM (#24229879) Homepage Journal

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

            • by TheSHAD0W (258774) on Thursday July 17, 2008 @12:10PM (#24230157) Homepage

              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)

          by IceCreamGuy (904648) on Thursday July 17, 2008 @09:59AM (#24228165) Homepage

          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.

        • by NickFortune (613926) on Thursday July 17, 2008 @10:15AM (#24228385) Homepage Journal

          At that point, slashdot and schneier.com are just trolling

          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.

        • by Goaway (82658)

          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)

          by elronxenu (117773)

          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

    • by fictionpuss (1136565) on Thursday July 17, 2008 @08:49AM (#24227297)

      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.

      • by bunratty (545641) on Thursday July 17, 2008 @08:56AM (#24227409)

        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.

        • Making a task harder does not necessarily limit production, especially if the new difficulty level still lies within the skill level of the individuals involved.

          Isn't the real problem that you're fighting against market forces which create a demand for the vulnerabilities in the first place?

        • by snspdaarf (1314399) on Thursday July 17, 2008 @11:10AM (#24229277)
          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.
        • by _Sprocket_ (42527) on Thursday July 17, 2008 @12:40PM (#24230573)

          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.

    • by dotancohen (1015143) on Thursday July 17, 2008 @08:52AM (#24227355) Homepage

      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.

      • by Tupper (1211) on Thursday July 17, 2008 @09:12AM (#24227581) Homepage
        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%.
        • Re: (Score:3, Interesting)

          by dotancohen (1015143)

          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?

          • by TheGreek (2403) on Thursday July 17, 2008 @09:34AM (#24227847)

            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?

            "Dear God, won't somebody please think of the children?"

          • by richlv (778496)

            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

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

              • by richlv (778496)

                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)

            by ShibaInu (694434)

            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.

        • by xtracto (837672) * on Thursday July 17, 2008 @09:45AM (#24227995) Journal

          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.

        • by dougmc (70836)

          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

      • by Hatta (162192)

        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.

        • 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)

            by rgviza (1303161)

            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)

              by gmack (197796)

              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

    • by sukotto (122876) on Thursday July 17, 2008 @09:37AM (#24227877)

      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?

      • by menace3society (768451) on Thursday July 17, 2008 @11:16AM (#24229365)

        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)

    by gparent (1242548) on Thursday July 17, 2008 @08:37AM (#24227123)
    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?
    • Re:What the... (Score:5, Insightful)

      by HungryHobo (1314109) on Thursday July 17, 2008 @08:43AM (#24227213)
      As the userbase shifts towards more mainstream users and away from the technically abled the percentage of users to whom the "who possesses the knowledge" actually applies drops and the number who are likely to be slow updating their systems goes up.This changes the game a little. I'm a supporter of the open model but I can see where they're coming from.
      • Re: (Score:3, Insightful)

        by atlep (36041)

        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)

      by hcmtnbiker (925661) on Thursday July 17, 2008 @10:07AM (#24228259)
      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?

      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.
      • by Fri13 (963421)

        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

  • by Novus (182265) on Thursday July 17, 2008 @08:38AM (#24227137) Homepage
    Note that the quote from Linus [marc.info] 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.

    • by zebslash (1107957)
      But only a diff will tell you where to look for the fix/vulnerability...
    • by Hatta (162192)

      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:3, Interesting)

      How is that any better? If I need to weigh security against stability, I need to know whether or not a patch fixes a major security bug on production machines or just changes obscure drivers that I don't even use. If I were to see a sudden increase in the number of attempted buffer overflows, I'm gonna want to check for known overflow attacks on the kernel and userspace programs I am administrating.

      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)

        by LO0G (606364)

        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

        • 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)

          by x2A (858210)

          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)

        by gmack (197796)

        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 would seem that if the vulnerability is patched in the change log, then it's fixed. I realize that some may need to run on an older kernel, but if a kernel developer found the vulnerability and fixed it, there is little way of knowing if anyone else (read black hat) has already known about it.
    • by gmack (197796)

      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.

  • by MikeRT (947531) on Thursday July 17, 2008 @08:40AM (#24227173) Homepage

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

    As long as the information is in there, isn't it part of their job to read through the changelog, read between the lines, and update appropriately? I have no mercy for the commercial groups that do their own distributions, and quite frankly, if they're going to play with the big boys, anyone who is rolling their own distribution should be put the effort into it to read the changelog for the kernel. It's not like some security hole in a fairly obscure or minor piece of software that they're having to look out for.

    • by betterunixthanunix (980855) on Thursday July 17, 2008 @09:00AM (#24227447)
      You say you have no mercy for commercial distributors, but the truth is that this sort of obscuration will only increase their business. Companies like Red Hat and Novell have the resources to pay people to spend all day reading through changelogs and deciding whether or not a patch is worth applying (in addition to people to are paid to submit patches). Universities may not have those resources, and their computer centers may only have enough time to quickly check a patch for common security fixes using grep. If it becomes impossible to do that, then all that we'll see is an increase in the number of people who buy support from commercial distributors, because they won't be able to support themselves.
      • by kipin (981566) on Thursday July 17, 2008 @09:28AM (#24227781) Homepage
        And what exactly is the problem with this method?
        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?
      • by MikeRT (947531) on Thursday July 17, 2008 @09:31AM (#24227821) Homepage

        If it becomes impossible to do that, then all that we'll see is an increase in the number of people who buy support from commercial distributors, because they won't be able to support themselves.

        The more demand for commercial support, the cheaper it will become. That means that eventually the cost to support university Linux-based systems via RedHat, Novell, etc. may become cheaper than the cost of keeping people on staff to do it. The end result is that while the universities may not be doing it for themselves anymore, it's cheaper for them to focus on what they do best. After all, no one seriously argues that society is worse off today because the average car owner cannot rebuild their car like a mechanic.

      • by gmack (197796)

        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.

      • this is exactly the point. The kernel is a software project, bugs are bugs, differentiating security bugs from the rest falls into the hands of those that do security audits. The presumption is that a developer ought to write secure code, when they don't it's a bug. Anything beyond that, is simply put: Not the developers job. The distributions are responsible for translating lower level information to the end user, not Linus.
  • by Anonymous Coward on Thursday July 17, 2008 @08:40AM (#24227183)

    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.

    • by Anonymous Coward on Thursday July 17, 2008 @10:02AM (#24228207)

      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.

      • Linus is entirely correct - a bug is a bug and must be fixed.

        It's not a bug, it's a feature.
        - Bill Gates.

  • by struppi (576767) <struppiNO@SPAMguglhupf.net> on Thursday July 17, 2008 @08:41AM (#24227191) Homepage
    The summary and the linked email from Brad Spengler look very flamebait to me. Linus Thorwalds writes in the quoted mail:

    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)

  • So (Score:5, Insightful)

    by C_Kode (102755) on Thursday July 17, 2008 @08:48AM (#24227285) Journal

    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.

  • by yerdaddy (93884) on Thursday July 17, 2008 @08:49AM (#24227303)

    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

  • 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)

    by delire (809063) on Thursday July 17, 2008 @08:52AM (#24227357)
    Looks like Brad is spinning things a bit. Further in the thread a 'Robert Peaslee' writes:

    Hi Brad, Your comments are kind of misguided. Linus can be quoted as saying: "my responsibility is to do a good job. And not pander to the people who want to turn security into a media circus." He was referring to individuals such as yourself when making the circus comment, as your message was slightly alarmist and dramatized. Security is important, of course - but Linus' opinions [kerneltrap.org] are completely correct in terms of development of the Linux kernel. I would agree with you if security bugs were actually being hidden, but they aren't. They just aren't given special treatment.

    From here [seclists.org]

  • Pragmatism (Score:3, Interesting)

    by jandersen (462034) on Thursday July 17, 2008 @08:53AM (#24227365)

    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.

  • 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

  • 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

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

  • by Medievalist (16032) on Thursday July 17, 2008 @09:50AM (#24228059)

    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

  • by rs232 (849320) on Thursday July 17, 2008 @10:00AM (#24228181)

    "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]

  • by rs232 (849320) on Thursday July 17, 2008 @10:13AM (#24228351)
    This, in my view, is total nonsense, if you don't mand me saying so, CmdrTaco. The full source is out there for anyone to see, bugs are reported in the kernel mailing list, for anyone to see. How is this in any way shape or form 'security through obscurity'
  • I knew it couldn't last. Oh well. There is always FreeBSD.

    • 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!

  • by rs232 (849320) on Thursday July 17, 2008 @10:15AM (#24228383)
    corrected headline .. :)
  • 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)

    by Anonymous Coward

    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

  • by swordgeek (112599) on Thursday July 17, 2008 @10:59AM (#24229097) Journal

    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.

  • by pembo13 (770295) on Thursday July 17, 2008 @12:09PM (#24230149) Homepage

    Most of the controversy is totally misplaced. This is essentially about having
    * SECUIRTY ISSUE: fix info
    vs.
    * fix info

    Is that really obscurity?

"No job too big; no fee too big!" -- Dr. Peter Venkman, "Ghost-busters"

Working...