This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Policy for posting security bug reports?
- From: Carlos O'Donell <carlos_odonell at mentor dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: <libc-alpha at sourceware dot org>, Jeff Law <law at redhat dot com>, Paul Eggert<eggert at cs dot ucla dot edu>
- Date: Mon, 25 Jun 2012 13:14:35 -0400
- Subject: Re: Policy for posting security bug reports?
- References: <20120623010836.GA2651@brightrain.aerifal.cx>
On 6/22/2012 9:08 PM, Rich Felker wrote:
> Hi all,
>
> I first asked Carlos about this off-list, and he suggested it should
> be discussed on-list. What is the policy (or what should it be) for
> posting security-related bugs to the bug tracker and/or list?
>
> At the moment, the bug I'd like to report is something I would
> consider moderate severity; it's in a family of interfaces that aren't
> often used in programs running with elevated privilegs, but if
> exploited, it leads to memory corruption that could result in
> arbitrary code execution. I can provide a patch to fix it along with
> the report.
>
> Of course, it would be nice to have a general policy.
Rich, Jeff, Paul,
My opinion regarding security bugs is as follows:
(a) We need a formal policy about security bugs, and it should
be documented and thus easy for submitters to follow.
(b) Where possible the policy should use already established
official channels for security issue reporting. For example
reporting the issue with CERT is IMO the best way forward.
The GNU Libc project and the distributions can have liaisons
with CERT, and receive early warnings from them in private.
(c) I want to avoid duplicating the good work done by other
security-related organizations like CERT.
Does this make sense?
To that end, (a) would be a list of instructions for how
to submit a security issue to CERT, and might include
such steps as:
* Contact the glibc CERT liaison listed on the MAINTAINERS
page and have them give you a first pass review of
the issue.
* Contact the machine maintainer listed on the MAINTAINERS
page for every machine explicitly affected by the issue.
* Contact the distribution contact listed on the MAINTAINERS
page for every distribution affected by the issue.
* Include in your CERT report all relevant details about
the issue including...
https://forms.cert.org/VulReport/
...
etc. etc.
Comments?
Rich,
Would you be willing to draft such a policy document for the
community to follow?
Cheers,
Carlos.
--
Carlos O'Donell
Mentor Graphics / CodeSourcery
carlos_odonell@mentor.com
carlos@codesourcery.com
+1 (613) 963 1026