Reporting Kernel Security Issues 75
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."
Good idea? (Score:5, Insightful)
Re:Good idea? (Score:5, Insightful)
A single point of contact is a good thing in my book.
Re:Good idea? (Score:4, Insightful)
But if it's a security problem in the kernel and it gets reported to the vendor currently instead of lkml, what makes you think a single point of contact will be used properly?
Re:Good idea? partially? (Score:4, Interesting)
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.
Re:Good idea? (Score:1, Informative)
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.
Re:Good idea? (Score:2, Informative)
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 avail
Re:Good idea? (Score:2)
Re:Good idea? (Score:1)
Re:Good idea? (Score:5, Insightful)
a) all bugs get published "public"
- each and every person can snoop around and either help fix it
- or instead try to exploit it (even moreso, keep on exploiting it on "unpatched" systems long time after)
OR
b) all serious bugs get published "privately"
- only "core contributors" get to see it and try to fix it
- 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)
Well, I guess (some) people prefer "version B"
Re:Good idea? (Score:2)
Re:Good idea? (Score:2)
so I could
1) fix it myself
or
2) be aware of activity to watch out for should a work around / fix not be available
Amazon use Linux and no doubt have *very* compentent Linux people on the staff, which do you think they would like to see ?
Re:Good idea? (Score:1)
so I could
1) fix it myself
or
2) be aware of activity to watch out for should a
work around / fix not be available
Amazon use Linux and no doubt have *very*
compentent Linux people on the staff,
which do you think they would like to see ?
I agre but how about this.
Make the unstable kernel bugs public and then ONLY after these bugs are fixed publically, allow private fixing of bugs in the stable kernel.
I'm not sure though. If in doubt, should we not just keep ALL bugs public???
Re:Good idea? (Score:2)
Either way, upgrades must be done at some point, and if the machines are not upgraded (and many won't), the exploit can be unleashed against those machines.
And that is really no different than what happens in the Windows environment.
Re:Good idea? (Score:2)
Either way, upgrades must be done at some point, and if the machines are not upgraded (and many won't), the exploit can be unleashed against those machines.
The point is that in B Joe-Random-Sysadmin can just type "apt-get update" and get a fixed, QA-ed stable kernel which is supported by his ven
make stable kernel bugs private? (Score:5, Interesting)
Re:make stable kernel bugs private? (Score:2)
Even worse, by keeping it private you also minimize the amount of developpers who are exposed to the mistake and the fix. By knowing about it they might not make the same or a similar mistake again in their own code.
Jeroen
Re:make stable kernel bugs private? (Score:1)
But, I agree, keep it all public - only way to be sre
Stop releasing advisories? (Score:2)
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.
Re:Good idea? (Score:2, Insightful)
...and wasn't Linux all about "version A" ? Sure, full disclosure has it's pros and cons, but there is no way to fix the cons without giving up the whole philosophy altogether.
I was completely astouned to hear that Linus himself agreed for a 5-working-day embargo on making known security issues public. Even if it proves to promote security in general, Linux will lose some of it's openness and what's worse - at the very heart - which I consider the security of a system to be.
Today, if I choose Linux, I g
Re:Good idea? (Score:1, Interesting)
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 b
Re:Good idea? (Score:4, Insightful)
Nobody knowing about the bug doesn't make is less vulnerable.... It might make it less likely that somebody will abuse it, but the hole is still there.
Keeping it silent only works if you are the only one capable of finding it. It has been shown time after time that that isn't true.
Jeroen
Re:Good idea? (Score:3, Interesting)
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 bu
Time-limited privacy (Score:3, Interesting)
Keeping "limited delay" short is the key.
Re:Good idea? (Score:3, Interesting)
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 ven
Working on my own DS_Linux (Score:5, Informative)
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!
Re:Working on my own DS_Linux (Score:1)
Re:Working on my own DS_Linux (Score:1, Offtopic)
You got modded down as well for asking this ;-) Often I see posts clearly moderated wrongly, and this is really just a testament of that particularly moderator cluelessness. Too bad metamoderation does not really work.
Re:Working on my own DS_Linux (Score:3, Insightful)
you say that like it's a bad thing ?
Re:Working on my own DS_Linux (Score:2)
Want an even newer kernel? Go with windows. And it's not like BSD's don't have innovations of their own. Look at NetBSD sometime -- there's stuff in there that's so elegant, you'll weep. FreeBSD has stuff like netgraph that has no parallel in Linux (but yeah, it's a shame FBSD has let netgraph more or less rot).
Aside from SELinux, I can't think of any advanced linux-specific kernel features that are all that mainstream. And frankly, til Lin
Re:Working on my own DS_Linux (Score:2, Informative)
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.
You are saying that the Linux kernel have unbelievable many security issues that are hard to fix? So the hard-to-fix bugs are results of design flaws and won't be fixed anytime soon?
I'd rather
It's a good idea (Score:2, Interesting)
Single point of contact a good thing (Score:5, Informative)
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.
Where's the "mish mash"? (Score:3, Informative)
Delegated and distributed != "mish mash".
Re:How to install Linux for mums (?) and dads: (Score:1, Offtopic)
yeah, my mum is much better as swapping out hard disks than putting in CDs
Re:How to install Linux for mums (?) and dads: (Score:2)
Re:How to install Linux for mums (?) and dads: (Score:2)
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 ;)
Re:How to install Linux for mums (?) and dads: (Score:2)
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.
Re:How to install Linux for mums (?) and dads: (Score:2)
Re:How to install Linux for mums (?) and dads: (Score:2)
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).
You mean we don't have one already? (Score:3, Informative)
Re:You mean we don't have one already? (Score:2)
Community problems? (Score:3, Informative)
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.
Re:Community problems? (Score:1)
This is to stop commercial third party patches (Score:4, Insightful)
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.
Finally! (Score:2)