Slashdot Mirror


Torvalds on the Linux Security Process

darthcamaro writes "Linus Torvalds thinks that Linux kernel security disclsoure should be completely open and he really doesn't like the vendor-security model of having a time embargo on security disclosure. 'I think kernel bugs should be fixed as soon as humanly possible, and any delay is basically just about making excuses,' Torvalds wrote. 'And that means that as many people as possible should know about the problem as early as possible, because any closed list (or even just anybody sending a message to me personally) just increases the risk of the thing getting lost and delayed for the wrong reasons.'"

44 of 280 comments (clear)

  1. You should listen to him... by Anonymous Coward · · Score: 3, Funny

    ...he propably knows what he's talking about.

    1. Re:You should listen to him... by sphealey · · Score: 5, Insightful
      Sorry to have to disagree, particularly about someone who is clearly far above my level in most respects, but .... Linus doesn't administer any significant number of Linux systems, nor is he responsible for any significant-sized networks. While I agree that full disclosure in a reasonable period of time (say 90 days) is best, immediate disclosure can leave thousands of systems vulnerable with no patches and no reasonable way to get them patched immediately even if a fix is available.

      sPh

    2. Re:You should listen to him... by ichimunki · · Score: 5, Insightful

      Disclosure or not, if there is an exploit possible your systems are vulnerable. Would you not prefer knowing right away that your system is vulnerable? The exploit may have been discovered some time ago by a black-hat--he won't wait 90 days for you to have a chance to patch it before exploiting it. What you're saying makes it sound like the bug doesn't exist until somebody talks about it.

      --
      I do not have a signature
    3. Re:You should listen to him... by MBAFK · · Score: 5, Informative
      The systems would still be vulnerable with no patch available. The administrators might not know there was a vulnerability but an attacker may know about it.

      Keeping it a secret might put you at a greater risk - you don't know you might be in trouble but the bad people know about the problem.

      So reducing the number of people who know about the problem could make it worse rather than better.

    4. Re:You should listen to him... by A+beautiful+mind · · Score: 4, Informative

      IF someone would have linked to the full discussion, it would have turned out that he suggested a 5 working day embargo on the disclosure MAX. They say and i think i have to agree, that it's enough time for vendors to catch up. Anything more just makes the problem worse. They will disclose everything after that embargo of course. There are a lot of good ideas and views and Linus refined his opinion more than once so it would be good to read the original discussion and not react based on the submitter's pick.

      Just to note, im reading LKML for over a year now and i read most of the mail about this thread aswell.

      --
      It takes a man to suffer ignorance and smile
      Be yourself no matter what they say
    5. Re:You should listen to him... by sphealey · · Score: 2, Insightful
      And why on earth would it be reasonable to take 90 days to produce what is usually something like an obvious 5-line kernel patch?
      Again keeping in mind that I am not disagreeing with you, it is still necessary to consider that (1) the patch is probably more than "5 lines", because otherwise it would have been found earler (2) security patches almost always IME have substantial side-effects and must be tested carefully (3) it takes longer than 5 days to QC, prepare, and release a patch for an enterprise-class system. I hope.

      sPh

    6. Re:You should listen to him... by Anonymous Coward · · Score: 3, Insightful

      Hey, it's great that you've got your MCSE and all, but that's not how things work or should work in open source development.

      A developer creates a fix and submits it to the maintainer. Note that the more people who know, the sooner on average somebody who can fix the bug will fix it and submit it.

      A maintainer checks the patch, and tries it out. If it seems to fix the problem, it's checked into the main code base, or possibly just to the development branch depending on severity and complexity. There's generally testing by volunteering users on the project's mailing list at this point as well.

      Once it's checked in, the distributions have access to it. At this point they'll do whatever level of quality control they deem appropriate given their base of users. Redhat probably has fast, set procedures for regression testing of most things. Gentoo may check in a package marked unstable and once it's tested enough flip it to stable.

      There's no part of this process where you can add 90 days of secrecy and expect good results.

    7. Re:You should listen to him... by motherjoe · · Score: 3, Interesting

      I think your damned if you do and damned if you don't.

      Your damned if you disclose, Black Hats can read the Kernel News groups, Butraq, and other popular outlets just like the rest of us do.

      Your damned if you don't disclose and a breach occures. The public will cry, "Security through Obscurity!"

      --
      "Beer is proof that God loves us and wants us to be happy - Benjamin Franklin"
    8. Re:You should listen to him... by Lumpy · · Score: 2, Insightful

      first off, let me remind you of something. if a good guy knows about a problem you bet that at least 2 bad guys know about it.

      Secondly the number of "hackers" (I know wrong term but security people refuse to use the proper term) is actually quite low, (yes this is true, go to HOPE, CCC camps and other events, 9 out of 10 people you meet are wannabe's, the number can omly increase cince the last ones I attended a few years ago) most of them out there are wannabe's and script-kiddies simply standing on the shoulders of giants by using their example exploit that was published or released.

      so a new security hole will certianly take time before there is a kiddie script ready.

      Who d oyou want to give the time to write software? the guys that can patch that hole or the black hat's trying to write a script or C program that will enable the thousands of me-too wankers trolling the IRC channels to attack?

      I personally want it released to the kernel-dev list the millisecond it is discovered. tell the people that know how to fix it what is wrong right away and they will have the fix out before the baddies have anything to use.

      --
      Do not look at laser with remaining good eye.
    9. Re:You should listen to him... by boodaman · · Score: 2, Informative

      As soon as more than one person knows them, secrets don't exist.

      If there is one person out there who knows about a vulnerability and/or exploit, there is more than one, and that means your systems are at risk instantly, embargo or not.

      I'd rather know right away my systems are at risk...worst case, I walk over and yank the ethernet cable until the issue can be resolved. Waiting even 5 days means I'm vulnerable for those 5 days, which is unacceptable. I want the vulnerability fixed immediately. My company's clients would much rather know we took drastic measures to keep their data safe instead of sitting there with our asses hanging out waiting for some corporate vendor to put the best spin on things and generate a press release.

      90 days? You've got to be kidding...that means my systems and networks are sitting ducks for 90 days. Unacceptable.

      And yes, I do administer a significant number of Linux systems (and Solaris) so I know what I am talking about.

    10. Re:You should listen to him... by m50d · · Score: 4, Insightful

      If there is an undisclosed exploit, your systems are vulnerable to whoever has done a deep kernel audit and found it. If there is a disclosed exploit and no patch, your systems are vulnerable to every script kiddie out there. In the case of services which can be turned off you might be better with disclosure, but how the hell do you plan to turn off your kernel? I know which situation I prefer.

      --
      I am trolling
    11. Re:You should listen to him... by Herkum01 · · Score: 2, Insightful

      What you're saying makes it sound like the bug doesn't exist until somebody talks about it.

      Bugs, and problems in general, cannot be fixed until someone starts talking about it. To try to limit the knowledge of problem also limits the ability to find a solution.

    12. Re:You should listen to him... by ajs · · Score: 3, Informative

      "I just run "apt-get update && apt-get dist-upgrade" once a day"

      Ah, what a nice world you live in.

      I do that at home. At work, I would be in a world of hurt if I did that. I have thousands of machines running a mix of in-house and external software which customers rely on for mission-critical stuff. I can't install every little patch just because it might make my frobnitzer go faster, and even when I WANT a fix, it's got to be tested in various production configurations first to see if it breaks something (you'd be surprised how often a security fix breaks something).

      So I read security updates from the vendor, and install what needs to be installed as soon as I can. If those security updates are coming to me days, weeks or even months after the script kiddies started playing with the exploit code... ugh.

  2. What !? by Squatchman · · Score: 5, Funny

    kernel bugs

    Thou shalt not speak ill of the linux kernel!

    Oh wait, it's Linus.

  3. One person can't fix it alone. by teiresias · · Score: 5, Insightful

    any closed list (or even just anybody sending a message to me personally) just increases the risk of the thing getting lost and delayed for the wrong reasons.'"

    I think he really hit the nail on the head with that comment. I can't tell you the number of times CRs or issues have been sent to me through e-mail which have either been lost or forgotten about on my part (sorry). However, using tracking programs which the entire group has access to (we use Mantis) not only are the problems kept on fresh but people will remind me of them or if they are feeling particularly bold, fix them themselves.

    --
    -Teiresias
  4. Summation of the article by Nosf3ratu · · Score: 5, Insightful
    "Quite frankly, nobody should ever depend on the kernel having zero holes," Torvalds wrote. "We do our best, but if you want real security, you should have other shields in place."

    Bingo.

    --
    The old Lie: Dulce et decorum est Pro patria mori
    1. Re:Summation of the article by Stevyn · · Score: 5, Funny

      Yeah, like Service Pack 2. That's got a firewall and everything!

    2. Re:Summation of the article by Erik+Hensema · · Score: 4, Insightful

      You should never depend on a single point of failure. If kernel security is your single point of failure, then you're at risk.

      However, you also shouldn't depend solely on "other shields in place" for security. Those shields might fail too.

      A simple example is apache. It almost never is run as root, as a security measure. However, when an attacker succeeds in gaining webuser privileges, you'll have to depend on kernel security.

      In short: try to make software as bugfree as possible and use multiple barriers that will have to fail before an attacker can 0wn your machine.

      --

      This is your sig. There are thousands more, but this one is yours.

    3. Re:Summation of the article by colinleroy · · Score: 2, Insightful

      You should never depend on a single point of failure.

      Only pirates depend on points of failure ;-)
      I think you meant You should never depend on a single layer of protection. Multiple (and redundant, if possible) protections are less likely to fail at the same time.

      OTOH, multiple points of failure are no better than a single point of failure...

      --
      blah
  5. But... by nuclear305 · · Score: 5, Insightful

    "And that means that as many people as possible should know about the problem as early as possible, because any closed list (or even just anybody sending a message to me personally) just increases the risk of the thing getting lost and delayed for the wrong reasons.'"

    I don't disagree with what Linus is saying, but what difference does it make if 10 people are informed rather than 10 million when it still doesn't change the fact that only a select few can change the official kernel source? People in production environments aren't going to apply a patch created by Joe in his basement, they're going to want an official kernel patch.

    If the ones responsible for the affected part of the kernel are slow to handle a security issue, full disclosure IMHO is a bad thing.

    One could argue that full disclosure would motivate those responsible to fix the problem faster, but this is not always the case.

    If Linus is the only person that can change a specific part of the kernel, what good does notifying the world instead of just him do?

    1. Re:But... by ValentineMSmith · · Score: 2, Interesting
      But...

      Linus isn't the only one that can change any part of the kernel. You may be correct by saying that an enterprise level operation isn't going to accept a patch from you or me.

      I'd expect that most enterprise level IT operations have developers on staff (or available through some sort of outsourcing or support contract) that may add a temporary fix until an official patch is available.

      At the bare minimum, even if they don't want to craft a patch themselves, they can evaluate for themselves the security ramifications of the hole and possibly take other protective measures, up to and including disabling a part of the system temporarily until a fix is made.

      As a rough example, there's a difference in Microsoft saying, "There's a security problem in the Windows GDI that won't affect you unless you're running a specific video card.", and you being able to look at the source for the GDI and affirming it for yourself.

      --
      Karma: Chameleon - mostly influenced by bad '80s New Wave music
    2. Re:But... by duffbeer703 · · Score: 2, Interesting

      Folks at Red Hat, Suse/Novell or whereever can produce quick patches to their distros, provided that they know of the problem.

      Few people are using the "official" kernel these days anyway.

      --
      Conformity is the jailer of freedom and enemy of growth. -JFK
    3. Re:But... by DrSkwid · · Score: 4, Insightful

      If Linus is the only person that can change a specific part of the kernel, what good does notifying the world instead of just him do?

      Because some of us can change our own kernels while we wait for the official patch.

      --
      There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
  6. Closed Security by thegnu · · Score: 5, Funny

    I've never really gotten the mechanism whereby software giants keep their software secure by not telling anyone about the security hole until it's fixed. First, we know about information leaks. Secondly, it's terribly profitable for some people to sit around and figure out security holes so they can steal from people.

    Especially in the position that Microsoft is in, with the lion's share of the market, and a supposed interest in keeping my data secure, I would assume that the first move would be to notify their customers of any security hole that might be potentially harmful to me. Given the number of them, I guess it would keep my mailbox full, but I wouldn't mind.

    Oh, I don't use Windows. Nevermind. Yay for Linux (and Linus)!

    --
    Please stop stalking me, bro.
  7. There's a reason why Linus is Alpha-Geek.... by Anonymous Coward · · Score: 4, Insightful

    and this is it. I totally agree with his ideas and would prefer his solution -- total openness.

    "Otherwise it just becomes politics..." -- Linus Torvalds

  8. Best line from the article by krgallagher · · Score: 2, Informative
    "Quite frankly, nobody should ever depend on the kernel having zero holes," Torvalds wrote. "We do our best, but if you want real security, you should have other shields in place."

    Why would you have all your ports exposed with nothing running on them? I have a hardware firewall. I only run HTTP ad FTP when I need them and then turn them off when I am through. It is really just simple security. Be smart. Oh yeah I subscribe to security lists and patch when security patches are released.

    --

    Insert Generic Sig Here:

    1. Re:Best line from the article by ZorinLynx · · Score: 2, Informative

      This doesn't work in all situations. For instance, at a university where you have a system a large number of students can log into.

      Kernel local root escalations don't affect MOST systems, but those few systems where a large number of arbritrary users can log into them to work on projects and such are highly vulnerable to them. Especially in an academic environment where a student might be tempted to try to crack root to peek at someone else's work.

      -Z

  9. Re:I LOVE slashdot. by Nosf3ratu · · Score: 2, Insightful
    The difference being that kernel developers do their best and "Gates" doesn't.

    Gates doesn't (didn't) code anything himself. The two do not compare.

    --
    The old Lie: Dulce et decorum est Pro patria mori
  10. On Linus by stratjakt · · Score: 2, Insightful

    Linus is the only figure in the entire OSS movement who doesn't have his head shoved up his ass.

    Everything he says is practical. He's all about technology, not new-age computer "philosophy" or rhetoric. He doesn't go around promoting linux because he thinks "M$ is Gayer Thean AIdz!@!!", he does so only when he truly believes it's a good solution.

    Here he is showing it again. He believes in full disclosure of bugs, not for any philosophical bullshit or imaginary right-to-know, but because it gets bugs fixed faster and improves the product.

    Once again, he's the only member of the OSS movement worthy of respect. He's the only reason businesses have considered linux an option, and the reason for any success it sees.

    The rest of the movements "figureheads" do more harm than good. Who else has been shot down when proposing a linux/OSS solution, having one of RMS's communist rants thrown back at them?

    --
    I don't need no instructions to know how to rock!!!!
    1. Re:On Linus by GoofyBoy · · Score: 2, Informative

      >He believes in full disclosure of bugs, not for any philosophical bullshit or imaginary right-to-know,

      No he doesn't.

      From the article:
      "I'd be very happy with a 'private' list in the sense that people wouldn't feel pressured to fix it that day," Torvalds wrote. "And I think it makes sense to have some policy where we don't necessarily make them public immediately in order to give people the time to discuss them.

      --
      The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
    2. Re:On Linus by ajs · · Score: 5, Insightful

      This is a massive distortion. There are dozens of folks who are just as level-headed as Linus. Linus happens to get the lion's share of attention from the community, which is a bit of a paradox given his personality, but he's not alone by a long shot.

      Now, if you're just thinking of the handfull of interview-bait folks like RMS, ESR, etc. then yes Linus does tend to stand out as a non-politico.

  11. Politics by RangerRick98 · · Score: 4, Insightful
    I've seen quite a few comments about systems being left vulnerable with no solution if immediate disclosure is the policy. But from TFA:

    "I'd be very happy with a 'private' list in the sense that people wouldn't feel pressured to fix it that day," Torvalds wrote. "And I think it makes sense to have some policy where we don't necessarily make them public immediately in order to give people the time to discuss them. But it should be very clear that no entity (neither the reporter nor any particular vendor/developer) can require silence, or ask for anything more than 'let's find the right solution.'"


    Linus is just trying to keep the politics out of it, is all. He's not saying that every bug should be made public knowledge immediately, only that things shouldn't be kept secret for reasons other than the security of the users' systems.
    --
    "You're older than you've ever been, and now you're even older."
  12. Mailing list thread by OblongPlatypus · · Score: 4, Informative

    Since the article is pretty much a copy/paste job from the lkml, why not link directly to the thread in question?

    --
    -- If no truths are spoken then no lies can hide --
  13. He's right, and here's why by Anonymous Coward · · Score: 3, Interesting
    It is very very rare that there is a security problem in the kernel that leaves you vulnerable with no work-around. Almost always, it's just a question of blocking external access to some port, external access which should usually be blocked anyway. Once that is blocked, solving the problem isn't critical. It's still important, but the net won't melt down or anything like that. Also, these kinds of things tend to get patched very quickly.


    The other reason why this is the right way to go is because we should be moving towards a model of damage containment with all forms of electronic security. Faults should be isolated. A security problem in one part of the code should not result in a total compromise of the system, even if that fault is in the kernel. That's where Linux should be heading. Part of that would be moving more stuff out of the kernel and also having less stuff running as root. The end goal would be to get rid of root entirely.

  14. Re:Lost? by actiondan · · Score: 2, Informative

    things can be delayed for the right reasons (e.g. for testing).

    I think the sentence is saying that things getting lost is not a desirable reason for a delay, which makes sense to me.

    Maybe if it said: "the risk of the thing getting lost and thus delayed for the wrong reasons", its intent would be clearer.

  15. Another good writeup on KernelTrap by Anonymous Coward · · Score: 2, Informative

    There's a good writeup on this thread at KernelTrap, too. Includes links to the full thread, which is quite fascinating.

  16. Re:So basically... by wild_berry · · Score: 2, Informative

    I think that TFA features Linus also saying that he's in favour of the security thing being closed so as to allow people time to discuss the problem and to not have to drop everything to fix the problem that day.

  17. No! by 91degrees · · Score: 4, Interesting

    Scenario 1: Bug is detected. Full disclosure including exploit.

    Result: Mallory uses exploit. Alice releases a bugfix, Bob applies the fix. If it takes Alice andBob longer than Mallory, the server is compromised.

    Scenario 2: Bug is detected. Kept quiet.

    Result: Eventually Mallory detects the same bug. Exploits it. Server compromised.

    Scenario 3: Bug is detected. Released only to trusted developers.

    Result: Alice releases bugfix. Announces that it fixes a security hole. Gives general details of what the bug is. Mallory has to work out the details and exploit it. This gives bob a lot more time to apply the patch than scenario 1.

    So what's so great about full immediate disclosure?

  18. Re:I LOVE slashdot. by Anonymous Coward · · Score: 2, Funny

    Actually, things are much worse than that.

    If Gates says this, people think: "Ah, a Linux based firewall/router, to protect my MSWindows systems!"
    Realistically, that's not a bad idea.

    If Torvalds says this, people think: "what should I now protect my system with? A Linux firewall doesn't make sense..."

    So there again MSWindows scores! With MSWindows, you can add Linux as an extra layer of protection, with Linux, it doesn't make sense!

    1-0 for Win vs Lin!

  19. Re:Notify on Vulnerability, don’t release the by finse · · Score: 2, Interesting

    While I see your point, I do not agree fully. If an exploit is not the wild when the vulnerability is discovered, providing the code will most certainly assist in accelerating the release of a worm or a script kiddy tool.

    --
    Paranoid tinfoil hat crowd say Y here, everyone else say N.
  20. I found Linus' arguments rather inconsistent by greppling · · Score: 2, Interesting
    At one point he said, he wants complete openness, everything else is just bad practice. Then he is fine with a short closed period.

    He says he never wants to wait applying a fix, because he wants to give users the best kernel possible. Then he says that it probably doesn't matter that the kernel.org kernel gets fixes last, because most users run vendor kernel anyway.

    But I think what annoys me most is that he is constantly claiming he is not forcing his (in his own admittance extreme) views on anybody. But this is just not true: In his position, he imposes his view on dealing with security issues on all kernel.org kernel users, and indirectly on vendor kernel users, just by the way he actually deals with them.

    From the discussion it turned out that the vanilla kernel often lacks security fixes because of Linus' complete refusal to work with vendor-sec. (2.6.10 got released with holes that had been fixed in 2.6.9-ac for a while.) And on the other hand, Alan Cox blamed him for quietly applying security fixes to his tree all the time; he actually said he is constantly reviewing the patches for this (since the blackhats obviously are doing the same).

    I think the full discussion is worth reading. It's an interesting clash of culture between people like Alan Cox, Marcelo Tosati etc. who have been working for a vendor for a long time and feel responsible for their users, and have thus adopted a rather pragmatic view, and the more fundamentalist full-disclosure of people arguing on Linus' side.

    Anyway, I am sure they will find a middle ground, because all agree that there is a need for a) a linux kernel security contact point (which will probably be a new closed mailing list with rather short disclosure timeline), and b) an established channel for announcing security holes (and maintaining security-fixes-only 2.x.y.z kernels).

    1. Re:I found Linus' arguments rather inconsistent by A+beautiful+mind · · Score: 2, Informative

      I couldn't quote the letter by word when he explained what you feel an incosistency but if you accept my interpretation of it, he said that his view about total openness may be a bit extreme SO he suggested this compromise between full embargo(vendor-sec) and total openness to strike a healthy balance.

      I just want to point out aswell that the reason why Linus doesn't want to do with anything with vendor-sec is politics.

      I have to point out on a sidenote though, but it seems to fit here that Andres Salomon started a new patchset, the "-as".

      "Hi,

      I'm announcing a new kernel tree; -as. The goal of this tree is to form a stable base for vendors/distributors to use for their kernels. In order to do this, I intend to include only security fixes and obvious bugfixes, from various sources. I do not intend to include driver updates, large subsystem fixes, cleanups, and so on. Basically, this is what I'd want 2.6.10.1 to contain."

      --
      It takes a man to suffer ignorance and smile
      Be yourself no matter what they say
  21. He's wrong, PLEASE READ by Alejo · · Score: 2, Interesting

    What if someone discovers a security bug, and they are really responsible professional researchers, and they want to give all affected vendors some time to come up with an official solution? (researchers, not ppl into 0day exploits or cracking or whatever)
    The way to do this is to have a multiple vendor coordinated release, where all agree on a date to release all together the alert and fix. This usually takes a few days, as most of them need to go through QA and other processes, as they are responsible to their customers.
    SecurityFocus offers such a service for FREE to any researcher/vendor.

    Blowing the whistle too early:
    Even with that, there is always some a**hole or some idiot vendor breaking this blanket period. See how RH fsckd up this, many times, and got themselves up to the point of being told late. Some other linux groups also did this, by "mentioning" the bug to uncontrolled developers who went fixing on their own, thus blowing the whistle.

    IF LINUS & CO LEAVE THIS COORDINATED SCHEMA, THEY'LL LOCK THEMSELVES OUT NOTIFICATIONS FROM RESPECTED RESEARCHERS.

    NOTE1: i have nothing against the 0day or the cracking comunities, im only stating IF a researcher wants to give a blanket to vendors. (a very common case)
    NOTE2: im not affiliated with SF, and even HATE the split bugtraq times for special vendors (i think this really killed it, a VV BAD move)
    NOTE3: you might not agree with this schema, but consider most top name security firms follow it and it is to protect the users.
    NOTE4: there is a defined period, so vendors are urged to come up with patch/alert
    NOTE5: think also for the poor devs working for those vendors, making them work overnight hurried is not polite, they are devs like all of us
    (im sure i miss some note and i'll get flamed anyway... flame on grrrrr)

  22. Linus is Right (by slippery slope) by ozborn · · Score: 2, Interesting

    Nevermind arguments about fixing bugs (although I think Linus is right here too). The important thing is to NOT let kernel security issues be driven by vendors perceived needs. Give vendors that, and they will run wild. Security is a favorite bugaboo under which any change be justified - kudos to Linus for not letting this happen. If they want to form a secret cabal where they can keep secret any kernel security issues they know about - fine (but stupid), but don't try to tell everybody else you can't talk about these issues.