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]

Message-ID: <alpine.LRH.2.02.1312131557340.32454@tundra.namei.org>
Date:	Fri, 13 Dec 2013 16:09:06 +1100 (EST)
From:	James Morris <jmorris@...ei.org>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
cc:	Dave Jones <davej@...hat.com>, Kees Cook <keescook@...omium.org>,
	"Theodore Ts'o" <tytso@....edu>, vegard.nossum@...cle.com,
	LKML <linux-kernel@...r.kernel.org>,
	Tommi Rantala <tt.rantala@...il.com>,
	Ingo Molnar <mingo@...nel.org>,
	"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>
Subject: Re: [PATCH 1/9] Known exploit detection

On Thu, 12 Dec 2013, Greg Kroah-Hartman wrote:

> On Thu, Dec 12, 2013 at 07:25:23PM -0500, Dave Jones wrote:
> > On Thu, Dec 12, 2013 at 01:13:41PM -0800, Kees Cook wrote:
> > 
> >  > - who will keep adding these triggers going forward?
> > 

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?


> > also..
> > 
> > - Who will test the existing triggers are doing the right thing when related code changes.
> 
> And:
>   - how do you determine an "expoit attempt" from "userspace program
>     doing something stupid" / "corrupted filesytem mounted"?
> 

Right, and if there are enough false positives, it'll end up being quite 
useless.

I suspect this kind of thing is better done in userspace anti-malware 
scanning.

> I really don't like this, it means that our normal error handling for
> userspace data will suddenly all have CVE entries on them over time.
> How is that helpful to anyone?
> 
> Think ahead in 10-20 years, what is the code paths going to look like
> then?  Horrible...

Agree.

This could make an interesting research project outside of the kernel. It 
doesn't belong in mainline without at least first being proven in the 
field and also properly maintained long term, if at all.


-- 
James Morris
<jmorris@...ei.org>
--
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/