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 00:46:40 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	James Morris <jmorris@...ei.org>
Cc:	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>,
	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 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.

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

I was wondering if we could do something using syscall tracing, or via
some systemtap kind of thing.  The problem is that this would be
painful for certain system calls, especially those that are
multiplexed, such as futex, or decode complex data structures based
via a pointer, or are context-dependent, such as ioctl's.

If it could be kept to a single exploit() line added to a return path,
the impact on code complexity and maintainability should be minimal.

I'm still a little dubious about the size of benefit that trying to
maintain these exploit() markets would provide, and whether it would
ultimately be worth the cost.

						- Ted
--
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/