Re: [PATCH 1/9] Known exploit detection

Vegard Nossum
2013-12-13T09:14:09Z

On 12/12/2013 10:13 PM, Kees Cook wrote:
> On Thu, Dec 12, 2013 at 11:06 AM, Theodore Ts'o <tytso@mit.edu> wrote:
>> On Thu, Dec 12, 2013 at 05:52:24PM +0100, vegard.nossum@oracle.com wrote:
>>> The idea is simple -- since different kernel versions are vulnerable to
>>> different root exploits, hackers most likely try multiple exploits before
>>> they actually succeed.
>
> I like it. I like how lightweight it is, and I like that it can be
> trivially compiled out. My concerns would be:
>
> - how do we avoid bikeshedding about which exploits are "serious
> enough" to trigger a report?

Well, I've already suggested that only bugs that potentially lead to
privilege escalation/intrusion (local and remote) would be candidates.
This probably includes any kind of buffer overflow or "wild write" bug.

Clearly, a bug should also be present over a complete release cycle
before it's worth annotating. A bug introduced in -rc1 and fixed in -rc5
is NOT a candidate.

> - who will keep adding these triggers going forward?
>
> I'm more than happy to assist with adding future triggers, but I don't
> want to be the only person doing it. :)

Thanks! Without making any promises, I am fairly sure that my team has
an interest in adding and maintaining triggers.

Based on some of the later comments in this thread, I think it might be
a good idea to keep a separate git tree for the triggers for a while.
You are of course welcome to contribute in any case.

Vegard