linux-kernel - Re: [RFC 1/1] seccomp: Add bitmask of allowed system calls.

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, 8 May 2009 12:37:30 +1000 (EST)
From:	James Morris <jmorris@...ei.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Adam Langley <agl@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Tom Zanussi <tzanussi@...il.com>,
	Li Zefan <lizf@...fujitsu.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	linux-kernel@...r.kernel.org, markus@...gle.com,
	linux-security-module@...r.kernel.org
Subject: Re: [RFC 1/1] seccomp: Add bitmask of allowed system calls.

On Fri, 8 May 2009, Ingo Molnar wrote:

> > In general, I believe that ftrace based solutions cannot safely 
> > validate arguments which are in user-space memory when multiple 
> > threads could be racing to change the memory between ftrace and 
> > the eventual copy_from_user. Because of this, many useful 
> > arguments (such as the sockaddr to connect, the filename to open 
> > etc) are out of reach. LSM hooks appear to be the best way to 
> > impose limits in such cases. (Which we are also experimenting 
> > with).
> 
> That assessment is incorrect, there's no difference between safety 
> here really.
> 
> LSM cannot magically inspect user-space memory either when multiple 
> threads may access it. The point would be to define filters for 
> system call _arguments_, which are inherently thread-local and safe.

LSM hooks are placed so that they can access objects safely, e.g. after 
copy_from_user() and with all apropriate kernel locks for that object 
held, and also with all security-relevant information available for the 
particular operation.

You cannot do this with system call interception: it's an inherently racy 
and limited mechanism (and very well known for being so).

I'm concerned that we're seeing yet another security scheme being designed 
on the fly, without a well-formed threat model, and without taking into 
account lessons learned from the seemingly endless parade of similar, 
failed schemes.

Please refer to (for example):

- "Traps and Pitfalls: Practical Problems in System Call Interposition 
  Based Security Tools" by Tal Garfinkel.

    http://www.stanford.edu/~talg/papers/traps/abstract.html

- "Exploiting Concurrency Vulnerabilities in System Call Wrappers" by 
  Robert Watson.

    http://www.watson.org/~robert/2007woot/




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