[Ksummit-2013-discuss] Topic Proposal: Handling Security Issues in the kernel

Kees Cook keescook at chromium.org
Tue Aug 13 02:30:44 UTC 2013


On Fri, Aug 9, 2013 at 1:13 PM, Greg KH <greg at kroah.com> wrote:
> 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
>> lacking.
>
> 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.

That's not happening as part of the regular process. There was no
notification, for example, from the security@ list to linux-distros@,
about the recent ARM fixes.

-Kees

-- 
Kees Cook
Chrome OS Security


More information about the Ksummit-2013-discuss mailing list