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.'"
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?
the risk of the thing getting lost and delayed for the wrong reasons
As opposed to getting lost for the right reasons?
bug.gd: error search engine. Humanity working together to solve all errors.
sPh
and this is it. I totally agree with his ideas and would prefer his solution -- total openness.
"Otherwise it just becomes politics..." -- Linus Torvalds
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."
When information about a security hole comes out it immediately begins dissemination in two different camps -- the white hats and the black hats. If dissemination is slower in the white hats than the black hats, it means that the black hats have a window of opportunity to compromise systems of people who would normally immediately patch. (why .... that would be me!)
Keep information dissemination free and open (fast) amongst the white hats and patches and workarounds will be available as fast as is possible.
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
sPh
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.
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.
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
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.