Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Security Software Linux

Security Holes Draw Linux Developers' Ire 477

Posted by timothy from the quick-draw-me-an-ire dept.
jd writes "In what looks to be a split that could potentially undermine efforts to assure people that Linux is secure and stable, the developers of the GRSecurity kit and RSBAC are getting increasingly angry over security holes in Linux and the design of the Linux Security Modules. LWN has published a short article by Brad Spengler, the guy behind GRSecurity and it has stoked up a fierce storm, with claims of critical patches being ignored, good security practices being ignored for political reasons, etc. Regardless of the merits of the case by either side, this needs to be aired and examined before it becomes more of a problem. Especially in light of the recent kernel vulnerability debated on Slashdot."
This discussion has been archived. No new comments can be posted.

Security Holes Draw Linux Developers' Ire More

Security Holes Draw Linux Developers' Ire

Comments Filter:

  • Time for (even) better security? (Score:5, Insightful)

    by moz25 ( 262020 ) on Monday January 10, 2005 @07:05AM (#11308973) Homepage
    Given that I'm getting lousy uptimes on my Linux servers because of the mandatory kernel upgrades, I certainly welcome a (constructive) critical look at Linux kernel security.
    • The biggest problem this poses is the PR to linux. If this news gets out big, corporate vendors will switch to some form of UNIX (sco, solaris, AIX) and Linux will be out of the business market.

      That's really all that keeps Linux abuzz aside from hobbiests.

      They really need to break out with these updates otherwise they'll get a worse rep on release times than Win too.
      • Oh, come on. Did you read the whole thing? This was over the holiday period, people are human. Additionally, Linus and M.M. were (as the writer noted) busy with other changes to the kernel.

        Listen to this and decide if it sounds more like a kid whining because they didn't get their way:

        Between December 15th and today, Linus has committed many changes to
        the kernel. Between January 2nd and today, Andrew Morton has committed
        several changes to the kernel. 3 weeks is a sufficient amount of time
        to be able to exp

        • Re:Time for (even) better security? (Score:4, Informative)

          by arkanes ( 521690 ) <(arkanes) (at) (gmail.com)> on Monday January 10, 2005 @09:15AM (#11309557) Homepage
          This sort of thing happens a lot in large open source projects. Joe Blow finds some (quite likely perfectly valid) bug or flaw or whatever, spends a lot of time creating and testing a patch, submits it and... nothing. It's ignored. Joe Blow gets very upset, occasionaly posts flames, takes his code and goes home, etc, etc. It's a valid problem. You have to look at it from the side of the project maintainers too, though - they don't know this guy, they don't know his code, and they don't have time to audit it for correctness. You need people willing to handle triage for patches and pass them up the chain. This isn't an especially fun or thankful job (although it's critically neccesary) so a lot of projects lack these sort of resources. However, the linux kernel DOES have these resources, and this guy should know better than to be all whiny that his personal patches aren't being fast-tracked.
          • Agreed. All he had to do was subscribe to the LKML (linux kernel mailing list), and he would have known that you can't just send a patch in out of the blue.

            He's a hypocrite to complain about how linux needs to be organized to receive patches, when he is himself ignoring the protocols already in place to deal with the problem.

            Imagine what would happen if linus had to personally look at every email about the kernel - nothing wold get done.

    • Given that I'm getting lousy uptimes on my Linux servers because of the mandatory kernel upgrades, I certainly welcome a (constructive) critical look at Linux kernel security.

      That's not the point. I am getting ready to force my Unix admins to patch their boxes on a more frequent basis than "yearly", and they are already screaming bloody murder. I am sick and tired of our Unix boxes getting rooted because some admin wants 365+ days of uptime and can't be bothered to test and install a kernel patch that fixes some important hole. That there is NO scheduled maintenance to start is an even larger problem that I'll rant about in a different post.

      And by the way, other Unix systems have capabilities, MAC labels, etc., and you know how most admins implement security on their systems? Every one of the Unix support team knows the root password, and the application support people use setuid scripts to administer their software, like they were doing in 1985. Capabilities, labels, and friends are extremely difficult to implement, and these features cannot save you from the one time a tired kernel programmer accidentally performs an unbounded input or forgets to check a counter. You will always need to patch your kernel (and reboot) in order to maintain operational security. Period. End of discussion.

      And if your only availability measurements are along the lines of

      for i in `cat hosts`; do ssh root@"$i" uptime >> uptime.report; done
      please get a clue: Availability doesn't include all of those times when your users tries to access a rooted system (even though the system is "up"), and it isn't a bad thing to schedule maintenance windows and notify the users and take the system down for patches or upgrades. In fact, I would much rather do so in a controlled fashion, as I can have backups made and documentation updated and I can take my time to do things correctly because I had time to test everything beforehand. Versus a 50+ hour nightmare/marathon starting with the pages from the instrusion detection system (or worse, from someone else's IT security department) at the wee hours of (if you are lucky) Saturday morning.

      So don't complain to me about lousy uptimes. Because when your server gets hacked because of a kernel bug patched three months ago, and you didn't apply the update because "my uptime counter will get reset" (i.e. you are lazy), I have to clean up your mess: Investigating the attack, determining the extent of the intrusion, validating the backups, etc.

      BAH. Rant mode off. I will spare you a discussion of the proper engineering processes that help to lessen (but not eliminate) the risk of security-related software flaws.

      • Don't worry, the last time any of my boxes was rooted was on the 10th of June 2002. I remember that day and all the trouble well enough to keep my systems up to date :-)

        If you're bashing me because you thought that I claim that uptime should take any priority over security: well, I do not hold that position.

        We routinely patch other software running on our systems, but those do not involve reboots and are easier to fix in case of problems. I do not see a problem with wishing for a lower frequency of mandat
  • but I don't really see much counterpoint. Anyone have URLs for where this has been discussed in some more depth?

    • Re:Interesting point of view (Score:5, Informative)

      by IamTheRealMike ( 537420 ) on Monday January 10, 2005 @07:16AM (#11309009)
      The bug mentioned in the LWN article was apparently not treated as serious by Andrew Morton and other developers on the grounds that there are far easier ways to DoS a system without using kernel exploits like that one. I don't know whether that's good or bad, but from debating things with various PaX guys myself I know they have a rather extreme approach to security (not something I'd ever give my grandma ...)

    • Re:Interesting point of view (Score:5, Informative)

      by 10Ghz ( 453478 ) on Monday January 10, 2005 @07:33AM (#11309055)
      Andrew Morton said [theaimsgroup.com]:

      An unprivileged local user can DoS a Linux box to death with malloc and
      memset, so the RLIMIT_MEMLOCK bug isn't particularly exceptional. All the
      others require root anyway.

      I'll pass this on to appropriate people, see if we can get this all fixed
      up, thanks.

  • Kind of an interesting contrast (Score:5, Insightful)

    by aendeuryu ( 844048 ) on Monday January 10, 2005 @07:08AM (#11308987)
    It's interesting to note that this comes out so recently after Linus was named one of ITs best managers. Lord knows he'd have to be to keep so many disgruntled people quelled. In the followup, somebody was citing as an excuse that Linus is one person and that there's only 24 hours in the day, so maybe some patches get missed. I was wondering, with all of the people he delegates to, isn't there somebody who handles all the security issues? Scroll down the LWN article, and somebody mentions that he needs a Kernel Security Officer, with no follow-up. Does Linus not have one of these guys yet?
    • It becomes a question of cost (in time) versus benefits.

      The people that are clammoring for this kind of extreme security are fringe factions. They know that if they want a posix environment with 007 grade military security, fedora core isn't what they should run. They're just raising a stink.

      Not to mention that, as mentioned elsewhere, I think one of the "holes" mentioned is something that is able to be attacked by DDoS. Newsflash: there are a lot of things that are attackable by DDoS, and it isn't as

  • So it begins. (Score:5, Insightful)

    by Anonymous Coward on Monday January 10, 2005 @07:11AM (#11308994)
    The trade off between security versus usability/accessability begins?

    Will Linux strike the perfect balance? Will Linux be taken over by a lunatic like Theo and go the OpenBSD route? Will Linux lose it's viginity to Windows and become a security nightmare? Stay tuned! All this and more on the next episode of OS wars!
    • The trade off between security versus usability/accessability begins?

      Perhaps. If it does, I'm betting heavily on the latter. A useful product with poor security has much more value than a secure product with poor usability.

  • ...oh, wait - I AM running Novell Linux. Oops. Um, I should tehn run and hide in a closet?
    Maybe I should implement security measures and have a good backup system?
    Nah!
    This kind of reminds me about all the people telling me you could die while driving a car - no s---, Sherlock! Use common sense.

  • Here it comes (Score:2, Insightful)

    by Tangwei ( 704210 )
    For years now people have been carrying the Linux flag due to the fact that its "more secure then windows"... guess what people.. time for being an unknown, unpopular OS is at hand... welcome to being known.

    • Re:Here it comes (Score:5, Interesting)

      by I confirm I'm not a ( 720413 ) on Monday January 10, 2005 @07:47AM (#11309095) Journal

      If I read you correctly you're saying that Linux's new-found popularity will cause lots of previously unknown security flaws to become evident. Do you believe either (a) Linux will ultimately have a similar number of security flaws as the Windows kernel, or (b) Linux will ultimately have a similar number of security flaws as Apache (an open-source, industry-leading application)?

      What I'm getting at is: security through obscurity is largely regarded as flawed (outside military intelligence circles), and the open-source/free-software development model has - time and again - resulted in bugs being shallow (IIS is closed-source and buggy. Apache is open-source and - relatively - secure).

      Everytime - everytime! - there's a security issue with Linux a troll pops up and says "ha! ha!" in their best Nelson Muntz voice: as if Linux was somehow perfect, but has now spectacularly fallen from grace. I don't know whether you're trolling as you don't really say much, and I found it difficult to understand much of what you did say, so my apologies if I'm way off base here, but...are you suggesting that Windows is "more secure than Linux", or what?

  • Maybe it's time... (Score:5, Insightful)

    by Jace of Fuse! ( 72042 ) on Monday January 10, 2005 @07:35AM (#11309060) Homepage
    Maybe it's time everybody get off of their OS Religious High Horse and finally admited that an OS is only as stable and secure as the user who is administering it.

    My Windows XP machine is solid and secure. My FreeBSD machine is solid and secure. My Windows ME machine -- well -- it runs, and it's quarenteened so I suppose in some ways it's secure.

    Right now I'm installing Gentoo on a box so I'm going to see where this goes, but I am going into it with full realization that no OS is perfect, nor is it perfectly secure. This means that I'm going to take security as seriously with this machine as I do the rest of them.

    Having the source to an OS doesn't make it more secure if you don't read (or understand) every line of it.

    Why people think OSS is automatically more secure is something I never have really understood. There is some added comfort in knowing that most holes will be discovered and fixed promptly, but even that is an assumption one shouldn't bank on.

    • Re:Maybe it's time... (Score:5, Insightful)

      by I confirm I'm not a ( 720413 ) on Monday January 10, 2005 @08:05AM (#11309152) Journal

      I pretty much agree with you, but... (!)

      Having the source to an OS doesn't make it more secure if you don't read (or understand) every line of it. (my emphaisis)

      Having the source available for anyone to read can lead to the OS (app, library, whatever) being more secure. Assuming that a wide-enough group of people do actually read the code. I'm confident that this happens with Linux, the *BSDs, etc.

      Most people tend to equate OSS with secure, I'd guess, because security-through-obscurity is largely a false promise, and we recall that many-eyes-make-bugs-shallow. Both concepts that appeal to the type of geeks who are interested in security ;)

    • Re:Maybe it's time... (Score:3, Insightful)

      by Anonymous Coward

      Maybe it's time everybody get off of their OS Religious High Horse and finally admited that an OS is only as stable and secure as the user who is administering it.

      Everybody acknowledges that. But that doesn't mean that operating systems are all alike. Linux - out of the box - is far more secure than Windows, and far less secure than OpenBSD.

      My Windows XP machine is solid and secure.

      Really? The last time I tried to secure a Windows machine, Microsoft had a list of 200-odd things to change, inclu

  • Grsecurity is for real (Score:4, Insightful)

    by Anonymous Coward on Monday January 10, 2005 @07:36AM (#11309065)
    Grsecurity guys (Brad and the pax guy mostly) are dead serious. They have been researching their areas of memory management, protection and secure code for years. They really do know it pretty much all. For instance the "AMD NX protection!!!!" that the Redhat raved about was copied from Pax. (Without even crediting properly.)

    They are just the sort of real gurus that can spot new vulnerabilities from code and exploit them in a matter of minutes. When Grsecurity was having serious funding problems last summer Brad was forced to sell new vulnerabilities from Linux kernel code to unmentioned blackhat companies. (Those do exist, believe me. They are doing commercial intelligence, stealing trade secrets with the knownledge..)

    Those guys are technically brilliant, years ahead of what Linux stock kernel has in security features. They are just a bit arrogant and bad with people. Also at the same moment the upstream kernel developers don't like being told that their stuff is complete crap on some area. They downplay it, ignore and use the "whoareyou,Iamthekerneldeveloper,youknownothing" tactic.

    Grsecurity guys could absolutely smash LSM by showing the vulnerabilities they are talking about as pocs. They are just a bit too disgusted and pissed off. There are several other areas like the exec_shield (that *is* atm getting to upstream kernel) that have big faults as well...

    They could prove their other points as well.. But it would be moot since they ARE correct in any case.

    • Re:Grsecurity is for real (Score:5, Insightful)

      by diegocgteleline.es ( 653730 ) on Monday January 10, 2005 @09:31AM (#11309677)
      "Exec shield" was not copied from PAX, it'd quite hard since the developer of "exec shield" (Ingo Molnar) admits that Pax covers more cases than PAX.

      It'd be nice if someone would ask the PAX developers why they modified their test suite to fail under exec shield. Run the pax test suite in a exec shield kernel and all the vulnerability simulations will succeed. That's not why exec shield is bad, it's because the test suite disables exec shield on purpose (you can disable exec shield, that's a feature)

      BTW, exec shield is not going in the kernel. Exec shield != "amd NX bit". The amd nx bit support has already gone in the kernel, but I'm not surprised at all that no grsecurity patch is going to the kernel. Grsecurity developers have NEVER submitted their patches to mainstream, they haven't even tried it, they haven't listened to constructive criticism. That's why grsecurity is not in the kernel and LSM is. They have just sit back saying "our stuff is better, use it" without even caring. There're lots of projects that have go poop because of that attitude. Remember the guy who rewrote the whole building infrastructure which never go in mainline? He updated his stuff regularly and critized Linus for not getting his obviosly better alternative. He didn't listen to Linus when he said "ok, just split it in small, individual parts" (like everybody else does) "and I'll merge it". When some other guy started to fix the available building system, the "Better stuff" went poop. Same will happen with LSM. LSM is bad? Well, what will happen if the developers decide to fix it, where will go grsecurity?

      I very much prefer a good developers/maintainer than a bad one, so I'll choose LSM at any time even if it is technically inferior. A good maintainer means that in the future he can rewrite his stuff if it's not good enought. That's much better than some guys who sit back in their mailing lists saying "our stuff is better"

    • Re:Grsecurity is for real (Score:5, Insightful)

      by arkanes ( 521690 ) <(arkanes) (at) (gmail.com)> on Monday January 10, 2005 @09:35AM (#11309708) Homepage
      ...Brad was forced to sell new vulnerabilities from Linux kernel code to unmentioned blackhat companies.

      So basically what you're saying is that these are the sort of guys who're so morally broken that they wouldn't pass even the most superficial of background checks for a sensitive position, which is no doubt why they need to get money by selling to blackhats rather than getting a real job in computer security. Basically, exactly the opposite of the sort of person you'd want to trust as a contributor security information and patches. Thanks, I'll remember to disregard anything I see from these morally challenged turdballs in the future.

  • distro with grsecurity (Score:3, Interesting)

    by UnderAttack ( 311872 ) on Monday January 10, 2005 @07:43AM (#11309085) Homepage
    Are there any distros out that include GRSecurity? I use it on all my 2.4 kernel boxes with great success and just started using it on production 2.6 systems. Overall, I find it to be very stable, and a very worth while extra layer of protection even without using the role based ACLs.

  • It's now been several days since the uselib() kernel exploit was posted and reports started to trickle in that it works. But there is no patch from the RedHat (or any other vendor, from what I've seen). What gives? Anyone got the inside scoop on what these vendors are saying on vendor-sec?

    The fact that it doesn't even show up in bugzilla makes me think it's still under embargo for some reason. Shouldn't the leak be sufficient reason to change their timeline? For those of us running production servers, this waiting game is more than a little inconvenient.

    On a side note, from what I've seen, the exploit has only been demonstrated on uniprocessor 2.4 kernels. Anyone get it to work on an SMP kernel, or a 2.6 kernel?

  • It's all too political (Score:5, Insightful)

    by m50d ( 797211 ) on Monday January 10, 2005 @07:58AM (#11309127) Homepage Journal
    With 2.6 there seems to be a bad trend towards far too much politics in the kernel. The cdrecord problems and reiser4 business (did that ever get sorted out?) together with the IMO stupid policy of putting new features in the stable branch (making deciding whether a feature can be added much harder, since it needs to be that much more stable and necessary before it can be added, but often you can't prove it's necessary without having some kernel branch running with it in) all smack of too much politics. Why can't people just concentrate on making the best kernel possible?

  • Start over, basing on OpenBSD for a change... (Score:5, Insightful)

    by ivi ( 126837 ) on Monday January 10, 2005 @08:01AM (#11309137)

    Long-time shell-provider SDF used Linux ...until they got hacked into.

    Now, it's a 64-bit version of NetBSD.

    OpenBSD claims:

    "Only one remote hole in the default install,
    in more than 8 years!"

    Why not start with a core built for security,
    - ie, rather than one built for popularity?

    My two cents...
    • Secure Dog Hosting [secdog.com] is using OpenBSD for all it's infrastructure. SecDog has been no 1 on Netcraft for longest uptime.

  • Wrong Recipient? (Score:4, Interesting)

    by z0ink ( 572154 ) on Monday January 10, 2005 @08:02AM (#11309139)
    According to LWN the advisories were sent to Linus Torvalds and Andrew Morton themselves. I'll admit that I don't know jack about the inner-workings of Linux Kernel development, but one would think that something of that nature would go out to the person in charge of security related issues or even out to the distributions to get a fix circulating. I could be dead wrong and maybe Linus is just the only guy running the show and decides when he'll spend some of his time patching the kernel. This also seems as a sort of public way of the author expressing his disdain towards Linux security and as a sort of publicity for his own system. Maybe I'm just too much of a cynic, but things aren't all they are cracked up to be. Please note that I am not saying that there isn't some sort of responsibility there, but that this seems overly hostile.
  • From the grsecurity page: "my personal gripe is that for 3 weeks not a single acknowledgement arrived in my mailbox, i don't think that's the way the chief developers are supposed to handle security issues (however small or irrelevant they may have been in this case - it takes a one liner to tell us so)."

    So ... rather than ask on the mailing list who is the best person for security submissions relating to whatever bug he found, he emails the top dude (during Christmas holidays no less) and then whines when no answer is forthcoming within his preferred timeline. Gimme a break!

    As a total noob, I went to kernel,org and found this on the first page:
    Please see http://www.kernel.org/pub/linux/docs/lkml/reportin g-bugs.html if you want to report a Linux kernel bug.

    http://www.tux.org/lkml/#ss5 explains why XX doesn't answer emails - too fricking busy is the usual reason.

    If I were concerned about publishing the bug, I would have asked ON THE LKML LIST for who would be the best person to submit security-related bug and patch to for the XX module.

    • Re:Waaah! 3 weeks without an answer! (Score:5, Funny)

      by R.Caley ( 126968 ) on Monday January 10, 2005 @08:31AM (#11309278)
      So ... rather than ask on the mailing list who is the best person for security submissions relating to whatever bug he found, he emails the top dude (during Christmas holidays no less) and then whines when no answer is forthcoming within his preferred timeline.

      I emailed Bill Gates to say that with a tunnelling electron microscope someone could adjust the logic in the CPU and DOS WindowsXP, and he hasn't answered me. Pout!

  • here's the essence of the gripe:

    (Posted Jan 10, 2005 11:26 UTC (Mon) by guest PaXTeam) (Post reply)

    lots of speculation so let's see the actual timeline a bit. spender emailed Linus sometime early december about the few issues he had found. he also mentioned some of the fixes that were in PaX, the result of one of them was this commit: http://linux.bkbits.net:8080/linux-2.6/cset@41bc90 0azV2y9... . understand please that we (well, spender at least) already had had a working two-way email connection wit

  • Patches are here (Score:3, Informative)

    by inode_buddha ( 576844 ) on Monday January 10, 2005 @08:22AM (#11309225) Journal
    >Hi all,
    >Is there a patch to uselib() bug ->
    >> http://www.isec.pl/vulnerabilities/isec-0021-useli b.txt ?

    Date: Sun, 09 Jan 2005 17:28:35 +0100
    From: Henrik Persson
    To: Breno Silva Pinto
    Cc: linux-kernel@vger.kernel.org
    Subject: Re: patch to uselib()

    It's patched in 2.4.29-rc1 and 2.6.10-ac6. A patch for 2.4 can also be found here:
    http://marc.theaimsgroup.com/?l=linux-kerne l&m=110 514006004261&w=2

    and for 2.6:
    http://marc.theaimsgroup.com/?l=linux-kernel &m=110 512844202355&w=2

    Browsing the archives usually gives you alot of answers, you know. ;)

    ----------------
    Cut-n-pasted from the LKML

  • wow... (Score:4, Informative)

    by advocate_one ( 662832 ) on Monday January 10, 2005 @08:27AM (#11309255)
    his beef is because he sent Linus an email on Dec 15th... [theaimsgroup.com]

    > Let me begin by giving you a timeline:
    >
    > December 15th: I send Linus a mail with a subject line of
    > "RLIMIT_MEMLOCK bypass with locked stack"
    > December 27th: The PaX team sends Linus a mail with a subject line of
    > "2.6.9+ mlockall/expand_down DoS by unprivileged users"
    > January 2nd: The PaX team resends the previous mail to Linux and Andrew
    > Morton
    >
    > Between December 15th and today, Linus has committed many changes to
    > the kernel. Between January 2nd and today, Andrew Morton has committed
    > several changes to the kernel. 3 weeks is a sufficient amount of time
    > to be able to expect even a reply about a given vulnerability. A patch
    > for the vulnerability was attached to the mails, and in the PaX team's
    > mails, a working exploit as well. Private notification of
    > vulnerabilities is a privilege, and when that privilege is abused by not
    > responding promptly, it deserves to be revoked.
    and he's made the assumption that Linus has actually seen the email??? After no reply for a day, he should have resent the email and kept resending it until Linus had sent him an acknowlegement... bloody stupid to send a critical email and assume receipt

  • broken development process (Score:5, Insightful)

    by Malor ( 3658 ) on Monday January 10, 2005 @08:42AM (#11309357) Journal
    From a security perspective, the current Linux development model is a nightmare. Introducing new features into the 'stable' codeline is not how to reduce bugs and problems.

    If I'm running 2.6.8, and a new bug comes out, I'm forced to either A) upgrade to the most recent 'stable' kernel, introducing new features about which I know nothing, and which themselves may be security problems, or B) can hope that someone will backport the security fixes to the kernel version I'm running. I don't know enough about kernel development to patch it myself, but I can no longer just drop in the most recent stable kernel and expect it to work unchanged.

    A sysadmin's most precious commodities are time and attention. With this new development model, suddenly I am forced to either pay a great deal of attention (and a great deal of time) to each and every version of the Linux kernel, or I need to pay a vendor to do it for me.

    The kernel developers are, in my opinion, shirking their single most fundamental duty... to ship a stable, secure product. Suddenly, because it's easier for them, they have abrogated the fundamental contract, that they will write great software. (buggy, insecure software is not great, no matter how many features it has.) They just wave their hands vaguely in the air and say tha the distributions will take care of those problems.

    Guys, it's not gonna happen. The way you get stable software is by not adding features. In your case, by branching off to 2.7, and letting us beat the unchanging (except for bugfixes) 2.6 tree to death. If you keep adding features, you keep adding bugs. That's how it works.

    You had this NAILED for years and years... there is a huge community that has built up around the fundamental social contract that even numbered kernels are as stable and secure as you know how to make them, and the odd-numbered branches are the home for new code and new features. Changing that contract simply becuase it makes your lives mildly easier is a hugely destructive idea. You may save yourselves a bit of work, but you create an enormous amount of it for everyone else.

    Ted T'So said:

    Not all 2.6.x kernels will be good; but if we do releases every 1 or 2 weeks, some of them *will* be good. The problem with the -rc releases is that we try to predict in advance which releases in advance will be stable, and we don't seem to be able to do a good job of that. If we do a release every week, my guess is that at least 1 in 3 releases will turn out to be stable enough for most purposes. But we won't know until after 2 or 3 days which releases will be the good ones.
    In other words, he thinks it's perfectly fine if only 1 out of 3 'stable' kernels are actually stable.

    This is not acceptable.

    You can bet that Bill has a big grin on his face about this one. If I want new features with my security fixes, I might as well choose Microsoft and their service packs.

    Heck, they even have a QA team!

    • The kernel developers are, in my opinion, shirking their single most fundamental duty

      Just a few questions:

      1. How much have you paid Linus, Alan Cox, Andrew Morton, et. al., directly?
      2. Did they make any promises to you about the reliability or stability of the kernel?
      3. Take a look at the GPL, particularly that explicit disclaimer of all warranties. Did Linus send you a certified mail letter in which he waived that clause for you?
      4. Did you get certified mail waivers of that clause from all the other kernel deve

    • Right on! (Score:5, Insightful)

      by Oestergaard ( 3005 ) on Monday January 10, 2005 @09:36AM (#11309722) Homepage
      You're absolutely correct in what you say.

      2.6 is currently a developer's dream and an administrator's nightmare.

      It is a smoking pile of bleeding edge patchwork. It can do everything in double time and brew coffee concurrently, but it cannot serve a file reliably (for example - as outrageous as it sounds that last part is actually the truth).

      The absolute major top-1 problem is the huge flux of patches; 4000 changesets between 2.6.9 and 2.6.10... One kernel fixes maybe 100 bugs and introduces the same number along with a heap of new features while it deprecates a few old interfaces.

      If 2.6.5 is the latest stable 2.6 kernel for one particular use (which I know for a fact that it is for some uses), you're stuck with a local root vulnerability because most likely 2.6.11 which may have a fix for this one bug will crash with that workload (as 2.6.6-2.6.10 did).

      And the examples I'm pulling out here (file serving and many unstable kernels in a row) are not unreported problems. They are not new problems. They have been worked on, partially fixed, etc. etc. but with the development model as it is, you just cannot expect fixes to have a very long life-time.

      It is very very sad. But I think it will change as someone realizes how bad the situation is. Probably half a year or so from now, when people start getting really annoyed that you *still* cannot route, web-serve or file-serve in any significant volume with Linux 2.6.

      Until then, it's Linux 2.4 and Solaris - both slow compared to 2.6 maybe, but at least they stay up over night :)

    • Re:broken development process (Score:4, Insightful)

      by iabervon ( 1971 ) on Monday January 10, 2005 @12:42PM (#11311333) Homepage Journal
      With respect to needing to switch versions to a kernel that is different in unexpected ways, it's exactly the same if you're running a 2.4 kernel.

      There are actually improvements with 2.6: the distros have been invited to take over 2.6.x.y series, so that if they're going to be backporting patches, they can contribute this effort back to the community. In 2.4, the distros carry so many patches that you'd have an easier time backporting from the latest 2.4 vanilla kernel than from a distro kernel with the same nominal version. They have so many patches because they feel the need to add functionality in their stable series.

      Also, Alan Cox is maintaining a tree of "really stable" kernels, where he takes only bugfixes from the current work and adds them to the base version he's using. I haven't determined if he's planning to continue 2.6.9-ac indefinitely, or if he's going to only release 2.6.10-ac kernels once he judges 2.6.10-ac to be sufficiently tested.

      The real issue is that Linus is currently in charge of releasing the stable versions. He's really good at identifying what should go into the stable series, from the perspective of guiding development, but he doesn't have the discipline to identify a completely-working version and call that 2.6.x. My prediction is that, in accordance with the ManagementStyle document, he will eventually decide that people complain about his release descisions, and therefore he should get somebody else (probably Alan Cox) to do that.

      As for development causing security problems, there has yet to be a 2.6 security hole in code that was added during 2.6. In general, new code is checked for all known patterns of bugs (almost all security holes fall into some pattern) and bad practices before being accepted. On occasion, a bug is found which is part of a new pattern, and future code with the same sort of bug will be caught, but existing code with that bug is not necessarily identified. This means that bugs are generally in code that hasn't been changed in a long time, not code which has been changed recently. In fact, there have often been bugs found in old versions which had already been eliminated unknowingly from new versions by people writing replacement code using improved techniques.

      For example, the recent hole was in code written ten years ago to facilitate the switch from a.out to ELF. The hole was a race condition due to changes made several years ago in the requirements of common code.

  • same feeling with S-ATA (Score:5, Informative)

    by davFr ( 679391 ) on Monday January 10, 2005 @09:15AM (#11309558)
    I experience the same feeling with S-ATA. There is an obvious issue with the S-ATA driver, which leads to data corruption with many drives and controlers (especially the Silicon Image 3112). But rather to stick on this problem until it's resolved, developers seems to continue in the "it's the hardware's fault" kind of statements. Nevertheless, one of my colleague, a NetBSD expert, tells me that this data corruption with S-ATA does not appear on NetBSD. And when I look in NetBSD mailing lists, I found nothing about data corruption on NetBSD. So what's next for Linux?

  • New development model to blame? (Score:5, Insightful)

    by bakreule ( 95098 ) <bkreulenNO@SPAMyahoo.com> on Monday January 10, 2005 @09:34AM (#11309701) Homepage
    I've always thought the new kernel development model was a bad idea. Instead of creating a new 2.7 branch for new code under development and letting the 2.6 branch stablize, the powers that be decided to put everything in 2.6. The downside of this is that there is no "stable" kernel as each new revision contains new "unstable" code and fixes for older versions. I'm not sure what the upside is.

    Some of these bugs, according to the article, have been around for ages, so the new dev model isn't to blame. But Linus and Andrew didn't even respond to these critical vulnerabilities....

    Just go ahead and create a 2.7 branch, and then assign a maintainer to the 2.6 branch and let it stabilize. I don't see any reason for not doing this.

  • Leaving the Door open for someone else (Score:5, Interesting)

    by tacocat ( 527354 ) <tallison1 AT twmi DOT rr DOT com> on Monday January 10, 2005 @11:00AM (#11310394)

    These kinds of security problems leave the door open for someone else to determine the future of Linux.

    You've just handed Microsoft a huge Public Relations goodie that they can beat to death as definitive proof that Linux fails to promptly fix security bugs. And now it can be extended to a universal problem with all Open Source Software. And now everything is back to being Microsoft or Death.

    Sure I exaggerate, but don't you think others will try to do the same?

    I don't know if the guy from GRsecurity can be classified as an asshole or not. I have found a lot of people who do post security patches tend to be very arrogant buttholes, but I've never met the guy. So there's some room here to determine just who's the bitch now.

    But if these are real security holes and have been around this long, we've lost a tremendous edge on what advantage Linux has been able to claim in the past. The door is open.

    My guess is that the best candidate is going to be OpenBSD or one of the other BSD's. It wouldn't surprise me. As something goes mainstream, it's political fat starts to overwhelm it's technical agility. To prevent this you have to fight very hard. Feature Creep is one name for this phenomenon. It could be argued that Linux has become focused on providing new and interesting features over old and boring performance expectations. This is to be expected as more people start pressing for wish list features and begin to ignore the original problems of security and stability. If you've ever wanted to see this in action - watch Debian. People are bitching now that Debian Unstable should be the defacto distribution version today and just wave their hands in dismissal when someone complains about packages breaking in Unstable. Apparently they too have accepted inherent stability problems in lieu of stability.

    This is dangerous for all organizations who do this. As the foundation is ignored, you will start to permit some really illusive bugs into the system.

    Similar extensions can be found when comparing Debian's Stable to Mandrake et al. Debian tends to be much slower on new developments, but they have a very good track record for basic performance. Similarly OpenBSD has it's software/hardware limitations, but it's definitely secure.

    And any arguements regarding the security of a system as installed from the distro-provider is pretty much BS. They have each decided to install towards a target audience. To expect to be able to execute an installation on an unprotected machine and have no security holes appear at any point in the process is more trouble than it's worth. The price of doing an installation behind a firewall is far lower and a waste of development resources.

Slashdot Top Deals

As you will see, I told them, in no uncertain terms, to see Figure one. -- Dave "First Strike" Pare

Close