linux-kernel - Re: [PATCH 1/9] Known exploit detection

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 13 Dec 2013 14:19:26 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Theodore Ts'o <tytso@....edu>, James Morris <jmorris@...ei.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Dave Jones <davej@...hat.com>,
	Kees Cook <keescook@...omium.org>, vegard.nossum@...cle.com,
	LKML <linux-kernel@...r.kernel.org>,
	Tommi Rantala <tt.rantala@...il.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Andy Lutomirski <luto@...capital.net>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Alan Cox <alan@...ux.intel.com>,
	Jason Wang <jasowang@...hat.com>,
	"David S. Miller" <davem@...emloft.net>,
	Dan Carpenter <dan.carpenter@...cle.com>,
	James Morris <james.l.morris@...cle.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 1/9] Known exploit detection


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