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

[Kees Cook]

On Wed, Aug 21, 2013 at 12:40 PM, Andy Lutomirski <luto at amacapital.net> wrote:
> 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.

Yeah, this is similar to what Debian and Ubuntu do. The "introduced"
and "fixed" stuff needs more careful thought, since there could be
multiple trees involved, not just Linus's tree. Though starting there
would be a good beginning. Even with that, where would sometimes be
multiple "Fixed-by" items.

Could go under Documentation/CVEs/ maybe?

-Kees

-- 
Kees Cook
Chrome OS Security