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.'"
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
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
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.
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?
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"
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.
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).
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)
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.