[Ksummit-2013-discuss] Topic Proposal: Handling Security Issues in the kernel
greg at kroah.com
Fri Aug 9 20:13:39 UTC 2013
On Fri, Aug 09, 2013 at 01:00:42PM -0700, James Bottomley wrote:
> On Fri, 2013-08-09 at 12:05 -0700, Greg KH wrote:
> > On Fri, Aug 09, 2013 at 11:56:10AM -0700, James Bottomley wrote:
> > > Assuming this one fails, I'd like to propose some oversight for our
> > > current murky security processes. The problem, as I see it, is that the
> > > current lists err on the side of secrecy because they're mostly run by
> > > security people, and security people love secrecy.
> > What are you classifying as our "current lists"? security at kernel.org is
> > _not_ run by security people at all.
> Really? Someone needs to update Documentation/SecurityBugs then because
> it says
> The Linux kernel security team can be contacted by email at
> <security at kernel.org>. This is a private list of security
> officers who will help verify the bug report and develop and
> release a fix.
Fair enough, but the people there are "normal" kernel developers, and it
does not consist of people who want to keep anything "secret", as you
can see by the rest of that document outlining what the process is, and
how we want to get stuff public as soon as possible.
> Perhaps we should start with actually being transparent about who the
> security team actually is ...
Sure, I don't mind posting the list of who is on that alias, but I don't
currently have it.
> > Also, some subsystmes (i.e.
> > networking) insist on never using that alias, and insist on always
> > sending stuff to netdev in order to have all of the networking
> > developers work on it. There's no reason that other subsystem
> > maintainers, if so inclined, can also do so.
> OK, so if we already have netdev as a working example of transparency,
> that supports my bold premise that we don't need secrecy.
Nice premise, I'll be glad to debate the other side if you wish :)
> > Other than that alias, I know of no such kernel security mailing list
> > that handles security issues (linux-distros is not a kernel list at
> > all, please don't get confused about that.)
> There's also vendor-sec and some of the cve lists. Interaction between
> these lists is how we get notified about security problems in the first
> place, but our transparency about how this all works is somewhat
Someone on security@ does notify linux-distros (the successor to
vendor-sec) of issues that are raised on it, so there is some
interaction there, but nothing more than that.
More information about the Ksummit-2013-discuss