Messages in this thread |  | | Date | Fri, 13 Dec 2013 10:12:03 +0100 | From | Vegard Nossum <> | Subject | Re: [PATCH 1/9] Known exploit detection |
| |
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
|  |