[Ksummit-2013-discuss] Topic Proposal: Handling Security Issues in the kernel
luto at amacapital.net
Tue Aug 13 16:37:29 UTC 2013
On Tue, Aug 13, 2013 at 9:20 AM, Kees Cook <keescook at chromium.org> wrote:
> On Tue, Aug 13, 2013 at 12:01 AM, Greg KH <greg at kroah.com> wrote:
>> On Tue, Aug 13, 2013 at 08:47:51AM +0200, Steffen Klassert wrote:
>>> On Sat, Aug 10, 2013 at 07:27:36PM +1000, James Morris wrote:
>>> > On Fri, 9 Aug 2013, Greg KH wrote:
>>> > > The number of bugs reported to security@ is very low, only a few a month
>>> > > turn out to be anything "real", and even then, most of them are quite
>>> > > limited in scope. So perhaps people are thinking there is more going on
>>> > > than really is, so some more transparancy would help out here after the
>>> > > fact?
>>> > Probably yes, although I think we need to examine the need to keep
>>> > security information out of upstream commits. The bad guys, particularly
>>> > well-funded ones, actually get an advantage when we do this, because
>>> > they'll figure out pretty quickly what the problem is, while the general
>>> > public is left in the dark for a time.
>>> > I think we need input on this from both the industry and from security
>>> > researchers.
>>> >From the point of view of someone who maintains vendor kernels where
>>> security is by far the most important issue, i'd wish some channel
>>> to get informed as soon as:
>>> a) A new security problem is reported, so that I can at least disable
>>> the related feature temporarily if needed/possible. Not sure if this
>>> should be done on a public list or on a channel where people have to
>>> confirm their needs to get informed.
>> Note that publically disabling features can be a signal to others that
>> there is a problem, and then that problem can be found "easier".
> I understood this to be about the time period between public
> disclosure and having a fix. Some times there is a long delay between
> the upstream fixes and when a distro/vendor can get a kernel rolled
> out with that fix. In that time frame, doing feature disabling is a
> nice way for vendors and end-users to work-around problems until the
> fix is available.
>> Anyway, linux-distros@ is the list for this.
> Yes. Please see http://oss-security.openwall.org/wiki/mailing-lists/distros
>>> b) A reported security problem is fixed with the related commit ID.
>>> Currently we are watching the cve lists to track this, but a linux
>>> kernel specific list would be much easier to track.
>> linux-distros@ is the list for this.
> Well, for public issues, oss-security@ is the right list.
> linux-distros@ is really only used for high priority
> embargo-coordinated issues.
> What's missing is an upstream accounting of commit ID that introduces
> a problem along with commit IDs that fix it. This can be cobbled
> together by the Mitre reports, but usually requires knowledge of the
> kernel area itself and some historical perspective. As yet, no one has
> stepped up to do this for the upstream kernels. (Distros do this on
> their own, generally.)
This is actually causing another sort of problem: some security people
are annoyed , and that's hindering reporting of new issues. (I'm
not going to comment on whether this is the right response by the
researchers, but it's certainly a problem for me right now.)
I'd propose a (quasi-)official list of known kernel vulnerabilities.
It could live in its own git tree (one text file per known
vulnerability, named by CVE number?), with private branches for
vulnerabilities that shouldn't be published yet.
(I could even be convinced to maintain such a thing for a while, but I
don't currently have access to any non-public vulnerability
 See the comments here: https://lwn.net/Articles/562488/
> Kees Cook
> Chrome OS Security
> Ksummit-2013-discuss mailing list
> Ksummit-2013-discuss at lists.linuxfoundation.org
AMA Capital Management, LLC
More information about the Ksummit-2013-discuss