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'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
"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.
yeah, my mum is much better as swapping out hard disks than putting in CDs
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
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.
Seriously, though, the root problem would not be addressed in this way. Need to make Linux maintenance foolproof for mum & dad (which, I realize, is a lot tougher and more time consuming than swapping a hard drive).
The NSA: The only part of the US government that actually listens.
She might be - you can draw a picture of which cables go where and how to mount it. You can't draw a picture of how to answer all the install/config questions and what to do with your data files. My idea is also recoverable (meaning you can easily go back if you want) and how much are hard drives - $40 for 40GB?
"Lawyers are for sucks."
- Doug McKenzie
What, like this?....
http://www.mandrakesoft.com/products/globetrotter
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.
Just FYI this scheme is already used; think it was linspire on seagate, but it was so long ago they started (months or even years) so I can't remember. Do some googling and see how it turned out.
you can draw a picture of which cables go where and how to mount it. You can't draw a picture of how to answer all the install/config questions and what to do with your data files.
When I read your original post, I assumed you meant that a hardware shop replaced the harddrive for mum and dad. Personally I think that proposal is great, though I share other people's concern about handing my mum a screwdriver and a diagram ;)
This is where the serious fun begins.
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.
Yeah, sorry I didn't make that more clear typing over my oatmeal. My idea is an is entirely reversible consumer-installed hardware upgrade that gets Linux on the desktop for under 40 samoleans.
"Lawyers are for sucks."
- Doug McKenzie
Hard drives cost more than that.
A real live person to send LSM vulnerability reports to.
- every person can try to exploit it on "unpatched" systems long time after
I think you forgot the Linux kernel is open source; if a bug isn't annouced publicly when it is found, it is publicly annouced by the patch that is produced to fix it.
I'd rather see the bug annouced publicly and fixed immediately than kept private, fixed eventually, and continue still be an issue on unpatched systems.
the rest of the population might not even know the bug exists until a patch is released (moreso, you might not even know what the bug was)
And you seriously think system administrators are taking the time to actually patch systems against a bug they know nothing about?
Because when a patch gets released and there will be an advisory coming with it, malicious cr4x0rz *will* know where the bug is and how to exploit it. So, your plan leaves no choice but to stop releasing kernel advisories.
In need of reliable and affordable server monitoring?
Delegated and distributed != "mish mash".
OK, 50 samoleans. Newegg has several 40GB hard drives under $50 US.
"Lawyers are for sucks."
- Doug McKenzie
Linux maintenance? What maintenance is necessary? There are no major spyware or virus issues (yet), and software updates are more or less automated at this point. Most important, these automated updates cover ALL of the software installed, not just Windows components. If you used Windows and Linux systems at the same level (in each case not installing random software downloaded from the internet), I think you would find that they are equally maintainable. If you are in a situation where the users are installing random software, you lose the maintainability in either case.
Bottom line: the boxed Linux distros are comparable to Windows if you are building a basic, functional system. Once users want to go beyond a basic system, Windows tends to give its users more rope to hang themselves with because it makes them feel like they are in a consequence-free environment and all the garbage is written for their system anyway. The nefarious software is not so readily available for Linux and that is what hurts it in terms of desktop acceptance more than anything else.
... have created a security team to privately handle the bugs...
It means they have created a team that can change anything unseenly.
I do,nt agree
"don't".