Messages in this thread | | | Date | Fri, 13 Dec 2013 00:46:40 -0500 | From | Theodore Ts'o <> | Subject | Re: [PATCH 1/9] Known exploit detection |
| |
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
| |