Re: [PATCH 1/9] Known exploit detection

[Ingo Molnar]

* Theodore Ts'o <tytso@xxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/