|| ||James Morris <jmorris-AT-namei.org> |
|| ||Ingo Molnar <mingo-AT-elte.hu> |
|| ||Re: [RFC 1/1] seccomp: Add bitmask of allowed system calls. |
|| ||Fri, 8 May 2009 12:37:30 +1000 (EST)|
|| ||Adam Langley <agl-AT-google.com>,
Andrew Morton <akpm-AT-linux-foundation.org>,
Tom Zanussi <tzanussi-AT-gmail.com>,
Li Zefan <lizf-AT-cn.fujitsu.com>,
Steven Rostedt <rostedt-AT-goodmis.org>,
|| ||Article, Thread
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
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,
Please refer to (for example):
- "Traps and Pitfalls: Practical Problems in System Call Interposition
Based Security Tools" by Tal Garfinkel.
- "Exploiting Concurrency Vulnerabilities in System Call Wrappers" by
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
to post comments)