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.'"
...he propably knows what he's talking about.
kernel bugs
Thou shalt not speak ill of the linux kernel!
Oh wait, it's Linus.
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
Bingo.
The old Lie: Dulce et decorum est Pro patria mori
"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?
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.
and this is it. I totally agree with his ideas and would prefer his solution -- total openness.
"Otherwise it just becomes politics..." -- Linus Torvalds
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:
Gates doesn't (didn't) code anything himself. The two do not compare.
The old Lie: Dulce et decorum est Pro patria mori
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!!!!
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."
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 --
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.
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.
There's a good writeup on this thread at KernelTrap, too. Includes links to the full thread, which is quite fascinating.
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.
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?
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!
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.