lkml.org 
[lkml]   [2013]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2013-12-13 14:41    [W:0.048 / U:2.652 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site