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

James Bottomley James.Bottomley at HansenPartnership.com
Fri Aug 9 18:56:10 UTC 2013


We seem to have reached the point in kernel development where "security"
is the magic word to escape from any kind of due process (it is, in
fact, starting to be used in much the same way the phrase "war on
terror" is used to abrogate due process usually required by the US
constitution).  A couple of recent example are:

http://lists.linuxfoundation.org/pipermail/ksummit-2013-discuss/2013-July/000116.html

and

http://marc.info/?l=linux-kernel&m=137549048712303

In both cases we had commits with cryptic messages, little explanation
and practically no review all in the name of security.

Our core processes for accepting code require transparency, review and
testing.  Secrecy in getting code into the kernel is therefore
fundamentally breaking this and risking the kinds of problems we see in
each of the instances.  I'd like to propose we do a review of our
security processes, what our standards for keeping something secret are
and how we might bring greater transparency to this rather murky area.

I'd like to start discussions with the big one:

      * Do we need to handle security vulnerabilities in secret?

This seems to be an obvious oxymoron, but if you look at both the
examples above, the vulnerabilities were already well known to the black
hat community and other exploiters, so the only people we really hurt by
preserving secrecy was ourselves (and possibly a few script kiddies who
are too dumb to follow the black hat lists).

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.  I think our
processes would be a lot more transparent if, in addition to the usual
security people, we had a couple of people on each list whose job was to
represent the interests of transparency: question why for each fix
security was necessary and be charged with reporting back to the
community the results of their efforts (including some follow up of
cases where they agreed to secrecy but perhaps in hind sight it was the
wrong decision).

James




More information about the Ksummit-2013-discuss mailing list