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

Stephen Hemminger stephen at networkplumber.org
Sat Aug 10 06:02:54 UTC 2013

On Fri, Aug 9, 2013 at 6:56 PM, James Morris <jmorris at namei.org> wrote:
> On Fri, 9 Aug 2013, James Bottomley wrote:
>> 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.
> This issue definitely needs discussion.  The cryptic / silent fixes are
> really only helping the bad guys.  They are watching these commits and
> doing security analysis on them.
> We don't have people with appropriate skill who are dedicated to doing
> security analysis on these kinds of fixes.  Perhaps the community via LF
> could find a way to make this happen, e.g. resourcing 2-3 security
> researchers to work specifically on mainline security triage.
>> I'd like to start discussions with the big one:
>>       * Do we need to handle security vulnerabilities in secret?
> That is an excellent question.  I think some expert input on the
> discussion would be useful from distro security response and security
> researchers.

It seems to me that the secrecy is more about avoiding sensationalist
news reports that might provide FUD to competitors.
For the enterprise products this kind of FUD might impact buying
decisions and even the financial markets.
But this short sighted policy means the number of eyes who actually
review the code is very small. Also, given that Linux is
everywhere, not just RHEL and SUSE getting fixes resolved and into
production is hard. I am sure there are 100000's of systems
out there with vulnerabilities that have been fixed 2 years ago. Maybe
making the process more open would not only
get more developers involved but reduce the long term exposure window.

More information about the Ksummit-2013-discuss mailing list