Messages in this thread | | | Date | Thu, 10 Sep 2015 08:35:43 -0500 | From | "Serge E. Hallyn" <> | Subject | Re: RFC: fsyscall |
| |
On Wed, Sep 09, 2015 at 02:33:14PM -0500, Eric W. Biederman wrote:
...
> If I assume that anything file descriptor based will need another > mechanism to filter what is allowed on a file descriptor, and as such > will need a different mechanism (capsicum perhaps?). That handily > reduces the problem space, and removes almost all cases where reading > data from userspace is interesting as I am talking about pure system calls. > > The list of system calls which are not file descriptor based are listed > below. Most of those don't take weird parameter structures that would > be interesting to filter. So I think my fsyscall idea is conceptually > reasonable. It is not a complete solution for passing someone a well > defined subset you are allowed to do but it is interesting.
...
> creat
Taking this as a specific example, I'm somewhat fond of the idea of saying that we can support openat() as fd-based (let's say capsicum-based as we know that can work), and therefore we don't need open() or creat(). If you're designing an app so that you can fork a task with a subset of your capabilities, then you're writing it now anyway, so there is no reason for supporting open and creat. Since these are specifically very subject to TOCTTOU, saying "you must use openat()" seems ok.
-serge
| |