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

[Posted May 12, 2009 by corbet]

From:		James Morris <jmorris-AT-namei.org>
To:		Ingo Molnar <mingo-AT-elte.hu>
Subject:		Re: [RFC 1/1] seccomp: Add bitmask of allowed system calls.
Date:		Fri, 8 May 2009 12:37:30 +1000 (EST)
Message-ID:		<alpine.LRH.2.00.0905081208480.2761@tundra.namei.org>
Cc:		Adam Langley <agl-AT-google.com>, Andrew Morton <akpm-AT-linux-foundation.org>, =?ISO-8859-15?Q?Fr=E9d=E9ric_Weisbecker?= <fweisbec-AT-gmail.com>, Tom Zanussi <tzanussi-AT-gmail.com>, Li Zefan <lizf-AT-cn.fujitsu.com>, Steven Rostedt <rostedt-AT-goodmis.org>, linux-kernel-AT-vger.kernel.org, markus-AT-google.com, linux-security-module-AT-vger.kernel.org
Archive‑link:		Article

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@namei.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html