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."
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.
No doubt my ignorance showing through but I am surprised there isn't a central repository for all kernel bugs, security or otherwise, already. Else, wouldn't there be a lot of "reinventing the wheel" going on?
The NSA: The only part of the US government that actually listens.
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.
No.
vendor-sec is a list where issues are discussed amongst vendors, and fixes are shared.
A bug is reported. People agree on a patch, or one is presented and given a quick check by other people - then at an agreed date all the vendors release their updates.
This means that large holes which affect core pieces of software such as the Kernel, Perl, Bind, OpenSSH all have a patch available from the vendor all at the same time - when the hole is reported.
Despite comments to the contrary bugs don't just sit their being "covered up", or held back arbitrarily - the whole point of the embargos/delays is to make sure all vendors who use the list are able to release together.
Well the headline made it seem like it was just a private list so that only the dev guys know about the problems. Now that I've gotten further through the thread it seems that Linus is uhh...strongly opposed to that idea.
No, he's strongly opposed to *long term* secrecy and any suppresion of a fix.
He's quite happy for short term secrecy, just not months worth. The thread drifted between four and fourteen days time with Alan Cox arguing for more so that commercial vendors could properly QA the fix.
Delegated and distributed != "mish mash".