oss-sec mailing list archives
Re: Vendor-sec hosting and future of closed lists
From: Dan Rosenberg <dan.j.rosenberg () gmail com>
Date: Thu, 3 Mar 2011 20:08:23 -0500
On Thu, Mar 3, 2011 at 7:41 PM, Greg KH <greg () kroah com> wrote:
On Thu, Mar 03, 2011 at 07:26:21PM -0500, Dan Rosenberg wrote:Rather than requiring individuals to perform substantial amounts of digging through patches, which I agree is infeasible, perhaps it would be more reasonable to establish a general policy that bug reporters and maintainers can use to work with distro security teams and the rest of the security community. For example, a public or private list could be established for all *potential* kernel security issues, and just as is the case with CC'ing stable, a policy could be developed where maintainers are expected to CC this list for fixes that might possibly have security relevance, with a tendency towards erring on the safe side if security impact is unclear.This proposal just fell down right there, as it has been rightly pointed out that numerous bug fixes in the kernel in the past have later been deemed "security fixes". So what you are asking for is for _all_ bugfixes to be sent to such a list. Well, we have that already, we have mailing lists that get every single patch that is merged into the kernel, and there's the big lkml list as well with hundreds of fixes posted every week.Of course failing to anticipate security impact is bound to happen in the kernel; it frequently happens in userland too, and is unavoidable. That doesn't mean we can't try, and it doesn't mean we should be overly paranoid and have security folks manually audit every patch. Currently, maintainers and bug reporters are expected to ask themselves a simple question when deciding whether or not to CC stable: "does this fix a bug or security issue, or is it a new feature?". Similarly, I don't think it's too much to ask for people to consider the question of "does this bug it allow an unprivileged user to crash the system, gain additional access, or otherwise cross privilege boundaries?" And if the answer is "I don't know, maybe?", then they should CC this list to be safe. I think this would result in not nearly as much volume as you're anticipating.They do this already today, that's what security () kernel org is for, and it gets a bit of traffic like this every week. I actually use that traffic to watch out for things that need to make sure they go into the stable releases. Those patches are then posted to stable () kernel org when they are public, so you can watch that list if you want.
The difference is that distributions and the security community do not have access to the security () kernel org list. The goal here to is bridge that communication gap - perhaps what's really needed is allowing more representation on the existing list and clarifying and encouraging policies for when CC'ing security () kernel org is appropriate, especially in regards to on-the-fence issues. If everyone were a bit more conscientious about e-mailing security () kernel org when appropriate and that list had better representation from people who can actually coordinate with various downstream vendors, that would be an improvement.
I think security communication needs to be improved at the commit level (as opposed to the reporting), since maintainers are often much more knowledgeable and better able to understand security impact than the users who are often presenting issues.I don't think you understand the rate of change in the kernel and how trying to do this for every commit is unfeasable and unworkable. You do know how fast it goes, right?Why is CC'ing a security list any more difficult than CC'ing stable?It's not, but if all you want to do is make sure the patch is applied to the stable trees as you think it's a potential problem, just copy stable instead. That's what happens today.
It's more about giving distributions the option of prioritizing security patches, and being more transparent about the potential risk introduced by certain issues. As you've said, even picking security fixes out of the stable queue is a substantial amount of work, and this could be made easier with a bit more openness. -Dan
Criteria could be set up for what kinds of issues would be candidates for being sent to this list. I don't think this would require substantially more work on anyone's part, but by creating a culture where potential security issues are treated seriously, it would at least stop some of the silent patching that's been going on. Once potential security issues have been submitted to such a list, I'm sure there would be no shortage of people willing and able to analyze security impact for each issue, including assigning CVEs. While digging through every kernel patch might be too much work, with the cooperation of maintainers this can be reduced to a much smaller subset that would be easily dealt with.I would be happy if someone could just document the patches that _are_ applied to stable kernel releases. I bet you can't keep up with that, they are moving so fast. Sorry, I don't think this is workable as you are proposing, but feel free to prove me wrong :)Perhaps you're right, but maybe we can generate some discussion to come up with a solution that improves upstream security communication and IS workable.Again, just try to start out by watching stable () kernel org and writing up summaries for the patches it applies and releases. I think you severly underestimate the work involved. But hey, what do I know, I could be totally wrong, it wouldn't be the first time today that happened :) thanks, greg k-h
Current thread:
- Re: Vendor-sec hosting and future of closed lists, (continued)
- Re: Vendor-sec hosting and future of closed lists Greg KH (Mar 03)
- Re: Vendor-sec hosting and future of closed lists Mike O'Connor (Mar 14)
- Re: Vendor-sec hosting and future of closed lists Eugene Teo (Mar 15)
- Re: Vendor-sec hosting and future of closed lists Mike O'Connor (Mar 15)
- RE: Vendor-sec hosting and future of closed lists Menkhus, Mark (GSE Security HP SSRT) (Mar 15)
- Re: Vendor-sec hosting and future of closed lists Eugene Teo (Mar 15)
- RE: Vendor-sec hosting and future of closed lists Menkhus, Mark (GSE Security HP SSRT) (Mar 16)
- Re: Vendor-sec hosting and future of closed lists Eugene Teo (Mar 16)
- RE: Vendor-sec hosting and future of closed lists Mark J Cox (Mar 16)
- Re: Vendor-sec hosting and future of closed lists Mike O'Connor (Mar 16)
- Re: Vendor-sec hosting and future of closed lists Dan Rosenberg (Mar 03)
- Re: Vendor-sec hosting and future of closed lists Greg KH (Mar 03)
- Re: Vendor-sec hosting and future of closed lists Mark J Cox (Mar 04)
- Re: Vendor-sec hosting and future of closed lists David Hicks (Mar 04)
- Re: Vendor-sec hosting and future of closed lists Nelson Elhage (Mar 04)
- Re: Vendor-sec hosting and future of closed lists Steven M. Christey (Mar 04)
- Re: Vendor-sec hosting and future of closed lists S.P.Zeidler (Mar 05)
- Re: Vendor-sec hosting and future of closed lists Greg KH (Mar 05)