Re: [PATCH 1/9] Known exploit detection

["Theodore Ts'o" <tytso@mit.edu>]

On Fri, Dec 13, 2013 at 04:09:06PM +1100, James Morris wrote:
> 
> I think we'd need to have someone commit to maintaining this long term 
> before seriously considering it as part of mainline.  Over time it will 
> become increasingly useless if new triggers aren't added.
> 
> What happens when code is refactored, who refactors the triggers?

We would definitely need to have test cases which deliberately trips
the triggers, which would be run regularly (which means they would
need to be included in the kernel tree), or else it's very likely as
the code gets refactor or even just modiied, the exploit() calls might
end up getting moved to the wrong place, or otherwise
deactivated/denatured.

> I suspect this kind of thing is better done in userspace anti-malware 
> scanning.

I was wondering if we could do something using syscall tracing, or via
some systemtap kind of thing.  The problem is that this would be
painful for certain system calls, especially those that are
multiplexed, such as futex, or decode complex data structures based
via a pointer, or are context-dependent, such as ioctl's.

If it could be kept to a single exploit() line added to a return path,
the impact on code complexity and maintainability should be minimal.

I'm still a little dubious about the size of benefit that trying to
maintain these exploit() markets would provide, and whether it would
ultimately be worth the cost.

						- Ted