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."
To be honest, I'd rather see any security problems in LKML, than keep them private...a private bug may not be fixed, but when there is a lot of public pressure to get a patch out, if it's not done *FAST* by the developers, someone in the community will do it. This is not the case if it is kept private.
On occasion I like to call it Santix, but I don't want to step on anyone's toes, so I just prepend my initials in front of "Linux" (RMS be damned).
The main thing that I try to focus on is security, and being on the LCML security mailing list has greatly improved my ability to find and squash security issues. You wouldn't believe how many security issues Linux has, actually. Luckily, most of the easy things like buffer exploits are already taken care of. The remaining issues are primarily involved in the timing issues of thread and process context switching. Exploiting the system vulnerability when it is grabbing and releasing resources. That kind of thing.
Whether or not the security list is part of the main LCML list is not really a primary concern. I'd rather have those guys working on features and we on the Security side can get those features secure. If we spent all our time thinking about how to make the system secure, we'd still be stuck with an age-old kernel like OpenBSD!
Keep those bug reports coming!
"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."
Err.. no - what they have done is create a single point of contact for security related bugs instead of the mish mash we have at the moment. That POC will work with the reporter to publish the bug.
Aren't these problems inevitable with any community-developed software, that the people who have input on to project need to be aware of problems on the project?
Unfortunately, trust is an issue: the inclusion of anyone who may be able to help out opens the doors to anyone who wants to attack. Additional complexity arises when the project is sold as a product; because the people using the product actually need to become involved in the community project too if they are to get the best support. Vendor-sec kind of does this for the Kernel, but the Kernel maintainers don't think that this is enough, because it's done reasons that are, broadly, not about making the best code as safe as possible (PR publication, politics are cited in the article, but I'm not involved and haven't seen).
If this one list gets set up, there will be a need also for trusted individuals to be included on any private security list to watch and make sure that bugs are squashed, not to code or argue about how to fix a hole. I understand that this would be anathema to the maintainers who want as few people as possible on such a list to stop leaks, but see it as an important part of the community process.
Most of the comments I've read so far seem to be missing the point. The idea of this security team is to make sure that there aren't any publicly known exploits in the kernel without a patch being available; at the moment this is inevitable if a bug is reported directly to the kernel guys, due to the policy of immediate disclosure.
This move is primarily to stop companies running linux from going to commercial vendors to patch their kernel for them, and thus keeping linux security centralised.
One good turn - gets all the covers.
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.