Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Security Programming Software Linux Technology

Reporting Kernel Security Issues 75

Posted by timothy from the top-men-are-working-on-it dept.
Omniscientist writes "A recent post on KernelTrap details the lkml post by Chris Wright talking about a centralized place to report security issues pertaining to the Linux Kernel and the discussion that was generated by it, including Chris's followup. It would appear that they now have created a security team to privately handle the bugs, who act as the alternative to reporting the flaw to the public immediately."
This discussion has been archived. No new comments can be posted.

Reporting Kernel Security Issues More

Reporting Kernel Security Issues

Comments Filter:

  • Good idea? (Score:5, Insightful)

    by lachlan76 ( 770870 ) on Wednesday February 02, 2005 @07:52AM (#11549386)
    To be honest, I'd rather see any security problems in LKML, than keep them private...a private bug may not be fixed, but when there is a lot of public pressure to get a patch out, if it's not done *FAST* by the developers, someone in the community will do it. This is not the case if it is kept private.

    • Re:Good idea? (Score:5, Insightful)

      by Anonymous Coward on Wednesday February 02, 2005 @07:57AM (#11549401)
      Did you actually read the fine thread? All Chris is doing is creating a single point of contact for security related bugs. The current situation is that bugs are reported randomly to lkml, distros or whereever so some may fall through the net.

      A single point of contact is a good thing in my book.

      • Re:Good idea? (Score:4, Insightful)

        by lachlan76 ( 770870 ) on Wednesday February 02, 2005 @08:10AM (#11549453)
        Well the headline made it seem like it was just a private list so that only the dev guys know about the problems. Now that I've gotten further through the thread it seems that Linus is uhh...strongly opposed to that idea.

        But if it's a security problem in the kernel and it gets reported to the vendor currently instead of lkml, what makes you think a single point of contact will be used properly?

        • Re:Good idea? partially? (Score:4, Interesting)

          by essreenim ( 647659 ) on Wednesday February 02, 2005 @08:51AM (#11549592)
          A single point of contact is a good thing in my book.

          As long as it is ALWAYS mirrored and PUBLIC. I do,nt agree with their idea to make encrypted bug reports preferable, digitally signed maybe but not encrypted. I can totally understand why Linus would be against it.

        • Re:Good idea? (Score:1, Informative)

          by Anonymous Coward
          Well the headline made it seem like it was just a private list so that only the dev guys know about the problems. Now that I've gotten further through the thread it seems that Linus is uhh...strongly opposed to that idea.

          No, he's strongly opposed to *long term* secrecy and any suppresion of a fix.

          He's quite happy for short term secrecy, just not months worth. The thread drifted between four and fourteen days time with Alan Cox arguing for more so that commercial vendors could properly QA the fix.
      • single point of failure.
    • I agree with this. Also the whole benefit is that its all open closing it off or making it private may result in all sorts of issues in the future.. (see microsoft's traditionally slow response to security issues.. aka win nuke).

    • Re:Good idea? (Score:5, Insightful)

      by tibike77 ( 611880 ) <.moc.oohay. .ta. .zemagekibit.> on Wednesday February 02, 2005 @08:00AM (#11549409) Journal
      Well, it's a tradeoff issue... do you prefer that:

      a) all bugs get published "public"
      - each and every person can snoop around and either help fix it
      - or instead try to exploit it (even moreso, keep on exploiting it on "unpatched" systems long time after)

      OR

      b) all serious bugs get published "privately"
      - only "core contributors" get to see it and try to fix it
      - the rest of the population might not even know the bug exists until a patch is released (moreso, you might not even know what the bug was)

      Well, I guess (some) people prefer "version B" ;)
      • Well personally I prefer A, but that's just me. We've seen how Microsoft have handled option b.
      • A

        so I could
        1) fix it myself
        or
        2) be aware of activity to watch out for should a work around / fix not be available

        Amazon use Linux and no doubt have *very* compentent Linux people on the staff, which do you think they would like to see ?

        • A
          so I could
          1) fix it myself
          or
          2) be aware of activity to watch out for should a
          work around / fix not be available

          Amazon use Linux and no doubt have *very*
          compentent Linux people on the staff,
          which do you think they would like to see ?
           I agre but how about this.

          Make the unstable kernel bugs public and then ONLY after these bugs are fixed publically, allow private fixing of bugs in the stable kernel.

          I'm not sure though. If in doubt, should we not just keep ALL bugs public???

      • I prefer "A", but that's because I want to know as soon as possible that I will be upgrading at some point. Yes, exploits may be created sooner that way, but even if you go with "B", exploits can still be created.

        Either way, upgrades must be done at some point, and if the machines are not upgraded (and many won't), the exploit can be unleashed against those machines.

        And that is really no different than what happens in the Windows environment.

        • I prefer "A", but that's because I want to know as soon as possible that I will be upgrading at some point. Yes, exploits may be created sooner that way, but even if you go with "B", exploits can still be created.

          Either way, upgrades must be done at some point, and if the machines are not upgraded (and many won't), the exploit can be unleashed against those machines.

          The point is that in B Joe-Random-Sysadmin can just type "apt-get update" and get a fixed, QA-ed stable kernel which is supported by his ven

      • make stable kernel bugs private? (Score:5, Interesting)

        by essreenim ( 647659 ) on Wednesday February 02, 2005 @08:54AM (#11549600)
        What bout this: a) all [unstable development kernel e.g 2.6.1] bugs get published "public" - each and every person can snoop around and either help fix it - or instead try to exploit it (even moreso, keep on exploiting it on "unpatched" systems long time after) But, keep [stable kernels] private.

        • Keeping bugs private doesn't prevent someone else from finding it and exploiting it.
          Even worse, by keeping it private you also minimize the amount of developpers who are exposed to the mistake and the fix. By knowing about it they might not make the same or a similar mistake again in their own code.

          Jeroen
      • the rest of the population might not even know the bug exists until a patch is released (moreso, you might not even know what the bug was)

        And you seriously think system administrators are taking the time to actually patch systems against a bug they know nothing about?
        Because when a patch gets released and there will be an advisory coming with it, malicious cr4x0rz *will* know where the bug is and how to exploit it. So, your plan leaves no choice but to stop releasing kernel advisories.

      • Re:Good idea? (Score:2, Insightful)

        by dmn ( 855563 )

        ...and wasn't Linux all about "version A" ? Sure, full disclosure has it's pros and cons, but there is no way to fix the cons without giving up the whole philosophy altogether.

        I was completely astouned to hear that Linus himself agreed for a 5-working-day embargo on making known security issues public. Even if it proves to promote security in general, Linux will lose some of it's openness and what's worse - at the very heart - which I consider the security of a system to be.

        Today, if I choose Linux, I g

    • Re:Good idea? (Score:1, Interesting)

      by coolcold ( 805170 )
      i actually prefer it to be made private....for a particular amount of time before making public.

      imagine, making a bug public can let more people solve the bug at the same time but also let hackers to exploit it. Making the bug on the other hand would slow down the patching process abit but systems are less vunerable. The bug won't exist forever in Linux since linux programmer aren't CEO like in M$ where money is their main motivation (which makes their programmer spend more time on features than fixing b

      • Re:Good idea? (Score:4, Insightful)

        by pe1rxq ( 141710 ) on Wednesday February 02, 2005 @08:29AM (#11549517) Homepage Journal
        but systems are less vunerable

        Nobody knowing about the bug doesn't make is less vulnerable.... It might make it less likely that somebody will abuse it, but the hole is still there.

        Keeping it silent only works if you are the only one capable of finding it. It has been shown time after time that that isn't true.

        Jeroen

      • Re:Good idea? (Score:3, Interesting)

        by EsbenMoseHansen ( 731150 )

        bug won't exist forever in Linux since linux programmer aren't CEO like in M$ where money is their main motivation (which makes their programmer spend more time on features than fixing bugs, leading to bugs not fixed for months). they WILL patch a system asap so this won't be an issue.

        I have seen repeatedly that this just isn't the case. Often bugs get ignored until it is released into the public, after which it is quickly closed. If you doubt me, try searching the Mozilla bug database after security bu

    • Time-limited privacy (Score:3, Interesting)

      by dpilot ( 134227 )
      Holding security holes private for a limited time does make sense, but the key word is *limited*. That delay is there for the sole purpose of making sure the fix is available when the hole is disclosed. The limited part means that nobody sits on security holes, and if it becomes public without a fix, the community kicks in. Even if a fix is announced along with the hole, it's entirely possible that the community will come up with a better/cleaner fix.

      Keeping "limited delay" short is the key.

    • Re:Good idea? (Score:3, Interesting)

      by jschottm ( 317343 )
      if it's not done *FAST* by the developers, someone in the community will do it

      The problem is that the moment it's disclosed, the blackhats also start 'doing it', except their task is often easier than that of the white hats. *FAST* releases may contain other safety flaws, bugs, break important things, or just not fix the bug. If keeping a bug [that there's no evidence of an exploit being in existance already] private for a week means that a fix is better tested and ready for release by all the major ven

  • Working on my own DS_Linux (Score:5, Informative)

    by Dancin_Santa ( 265275 ) <DancinSanta@gmail.com> on Wednesday February 02, 2005 @07:55AM (#11549393) Journal
    On occasion I like to call it Santix, but I don't want to step on anyone's toes, so I just prepend my initials in front of "Linux" (RMS be damned).

    The main thing that I try to focus on is security, and being on the LCML security mailing list has greatly improved my ability to find and squash security issues. You wouldn't believe how many security issues Linux has, actually. Luckily, most of the easy things like buffer exploits are already taken care of. The remaining issues are primarily involved in the timing issues of thread and process context switching. Exploiting the system vulnerability when it is grabbing and releasing resources. That kind of thing.

    Whether or not the security list is part of the main LCML list is not really a primary concern. I'd rather have those guys working on features and we on the Security side can get those features secure. If we spent all our time thinking about how to make the system secure, we'd still be stuck with an age-old kernel like OpenBSD!

    Keep those bug reports coming!
    • we'd still be stuck with an age-old kernel like OpenBSD

      you say that like it's a bad thing ?

    • > we'd still be stuck with an age-old kernel like OpenBSD!

      Want an even newer kernel? Go with windows. And it's not like BSD's don't have innovations of their own. Look at NetBSD sometime -- there's stuff in there that's so elegant, you'll weep. FreeBSD has stuff like netgraph that has no parallel in Linux (but yeah, it's a shame FBSD has let netgraph more or less rot).

      Aside from SELinux, I can't think of any advanced linux-specific kernel features that are all that mainstream. And frankly, til Lin

    • The main thing that I try to focus on is security, and being on the LCML security mailing list has greatly improved my ability to find and squash security issues. You wouldn't believe how many security issues Linux has, actually. Luckily, most of the easy things like buffer exploits are already taken care of.

      You are saying that the Linux kernel have unbelievable many security issues that are hard to fix? So the hard-to-fix bugs are results of design flaws and won't be fixed anytime soon?


      I'd rather

  • It's a good idea (Score:2, Interesting)

    by michelcultivo ( 524114 )
    It's a good idea to have a group that handles security bugs into linux kernel, now we need only that the people that claims herself as "serious" only report the bugs to the kernel-security@*. "Imagine all the people living bug free kernel :)"

  • Single point of contact a good thing (Score:5, Informative)

    by Anonymous Coward on Wednesday February 02, 2005 @08:02AM (#11549421)
    "It would appear that they now have created a security team to privately handle the bugs, who act as the alternative to reporting the flaw to the public immediately."

    Err.. no - what they have done is create a single point of contact for security related bugs instead of the mish mash we have at the moment. That POC will work with the reporter to publish the bug.

    • Where's the "mish mash"? (Score:3, Informative)

      by khasim ( 1285 )
      Err.. no - what they have done is create a single point of contact for security related bugs instead of the mish mash we have at the moment. That POC will work with the reporter to publish the bug.
      Right now, all you have to do is look up the name of the maintainer for the sub-system with the flaw and email him/her directly.

      Delegated and distributed != "mish mash".

  • You mean we don't have one already? (Score:3, Informative)

    by It doesn't come easy ( 695416 ) * on Wednesday February 02, 2005 @08:23AM (#11549484) Journal
    No doubt my ignorance showing through but I am surprised there isn't a central repository for all kernel bugs, security or otherwise, already. Else, wouldn't there be a lot of "reinventing the wheel" going on?
    • There is such a repository, but it is not monitored very closely, because it (rightly) accumulates all sorts of obscure notes which are useful for reference but not for informing people. There's a lot of "some hardware only I have misbehaves in some way" or "something nobody else ever tried to do doesn't work". You want this sort of information in case other people start having similar problems, but there's little incentive to fix the bug in a hurry, especially if the person found some way to avoid the prob

  • Community problems? (Score:3, Informative)

    by wild_berry ( 448019 ) on Wednesday February 02, 2005 @08:26AM (#11549498) Journal
    Aren't these problems inevitable with any community-developed software, that the people who have input on to project need to be aware of problems on the project?

    Unfortunately, trust is an issue: the inclusion of anyone who may be able to help out opens the doors to anyone who wants to attack. Additional complexity arises when the project is sold as a product; because the people using the product actually need to become involved in the community project too if they are to get the best support. Vendor-sec kind of does this for the Kernel, but the Kernel maintainers don't think that this is enough, because it's done reasons that are, broadly, not about making the best code as safe as possible (PR publication, politics are cited in the article, but I'm not involved and haven't seen).

    If this one list gets set up, there will be a need also for trusted individuals to be included on any private security list to watch and make sure that bugs are squashed, not to code or argue about how to fix a hole. I understand that this would be anathema to the maintainers who want as few people as possible on such a list to stop leaks, but see it as an important part of the community process.
    • I wrote this and then realise that Linus' intention is that people do trust him, saying that he would publish security vulnerabilities plainly so that people are not hidden from the real problems tha come with this enterprise. Linus also says that he understands this isn't entirely practical.

  • This is to stop commercial third party patches (Score:4, Insightful)

    by Jack Taylor ( 829836 ) on Wednesday February 02, 2005 @08:29AM (#11549521)
    Most of the comments I've read so far seem to be missing the point. The idea of this security team is to make sure that there aren't any publicly known exploits in the kernel without a patch being available; at the moment this is inevitable if a bug is reported directly to the kernel guys, due to the policy of immediate disclosure.

    This move is primarily to stop companies running linux from going to commercial vendors to patch their kernel for them, and thus keeping linux security centralised.
  • A real live person to send LSM vulnerability reports to.

Slashdot Top Deals

Our OS who art in CPU, UNIX be thy name. Thy programs run, thy syscalls done, In kernel as it is in user!

Close