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

Andy Lutomirski luto at amacapital.net
Wed Aug 21 19:40:49 UTC 2013


On Sat, Aug 17, 2013 at 8:43 AM, Kees Cook <keescook at chromium.org> wrote:
> On Sat, Aug 17, 2013 at 7:14 AM, Dan Carpenter <dan.carpenter at oracle.com> wrote:
>> If you find a security commit after the fact you can just report it
>> to linux-distros or stable.  Why are these not working?
>
> The issue is that other consumers of the kernel (those not on
> linux-distros) don't have a central place to get a list of fixes to
> pay attention to. Not everyone just takes everything from -stable, for
> example.
>
>> Ubuntu already has a list of break-fix hashes.  I don't like the
>> idea of having a break-fix file in the kernel.
>
> I still think having a list with break-fix, CVE, and a description of
> the potential impact would be of great service to people interested in
> that kind of thing. And when understanding of the impact changes, it
> gets updated, etc.
>

As a straw man proposal, there could be a git tree with files named
with CVE numbers.  (This could live in linux.git or outside.)  Files
could look like:

CVE: CVE-xxxx-yyyy
Reported: <date> <reporter>
Reported: <other date> <other reporter>
Impact: local-dos
Impact: local-resource-exhaustion
Impact: local-kernel-compromise
Impact: remote-doc
Introduced-by: <git commit>
Fixed-by: <git commit>
Public-exploit: url
[etc]

Text description here

Generating some kind of webpage, associated versions, etc
automatically would be straightforward.

--Andy


More information about the Ksummit-2013-discuss mailing list