Messages in this thread | | | Date | Fri, 13 Dec 2013 14:19:26 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH 1/9] Known exploit detection |
| |
* Theodore Ts'o <tytso@mit.edu> wrote:
> 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.
That looks useful for another reason as well: we had cases where the same exploit re-appeared because our fix against it regressed.
> [...] > > I'm still a little dubious about the size of benefit that trying to > maintain these exploit() markers would provide, and whether it would > ultimately be worth the cost.
These items are very easy to remove if any of them breaks or gets out of sync. So the cost can be reduced to zero, if the experiment fails.
I'd definitely be willing to accept the x86 and perf bits, if all complaints are fixed and if Vegard (and Kees?) volunteers to maintain this thing.
I see no real downside - other than giving the security circus a foothold in the kernel.
OTOH, such defensive measures _do_ have tangible benefits:
- They warn kernel developers about dangerous patterns and past incidents, in the code itself. There are 'hotspot' areas in the kernel that tend to attract more bugs than others.
- They give actual real figures to people/organizations: do these checks ever trigger? Have they triggered in the past 5 years? A large enough organization might be able to quantify and guesstimate its attack surface that way.
- We could actually insert such checks against known zero day exploits out in the wild. Those exploits will eventually be changed to be more careful, but there is going to be a delay with such updates: catching some attack attempts. Software update delays will finally work in favor of the good guys!
so maybe these effects reduce the security circus aspect. Or not :-)
Thanks,
Ingo
| |