Slashdot Mirror
Reporting Kernel Security Issues
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."
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 :)"
http://www.michel.eti.br
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 bugs, leading to bugs not fixed for months). they WILL patch a system asap so this won't be an issue.
However, if the bug is critical, making the bug private for, say a week, before going public would enable the developers to fix the bug. Only if the bug can't be fixed easily then it would be opened for others to help fixing it. This would make the machines in the wild less vunerable and also system patches quickly.
just my 0.02
I am harvesting funny/good quotes. Please help by putting them in your sigs
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.
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.
The living have better things to do than to continue hating the dead.
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 bugs. Their policy was 3 months before the bug was made public.
Openness is the only way. It is my uncomfortable experince. Sorry.
Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
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 vendors at the time of disclosure, I'm not sure that's a bad thing.
This is not the case if it is kept private.
That may be the case in commercial software, but I'm not sure if it would carry over to the open source world. I suspect that Linux has attracted a certain type of programmer whose involvement goes beyond the simple code==paycheck mindset. There are people being paid by various companies to work on the kernel, but they're generally the ones that demonstrated their commitment to working on Linux prior to getting hired specifically to do so.
The decentralized nature of the kernel means that it's not dependant on the whims of a single company or a few individuals within a single organization. $COMPANY has to worry about their stock price when a vulnerability is disclosed. There's much less impact on the core Linux programmers by such things.
I can't see Linus saying to himself, "No one knows about this problem, therefore I don't have to work on it yet." Can you?