Subject: Re: [RFC 1/1] seccomp: Add bitmask of allowed system calls.
Date: Friday 8th May 2009 02:37:30 UTC (over 8 years ago)
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 <[email protected]> -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html