Messages in this thread | | | Date | Thu, 8 Jan 2009 06:41:45 +0100 | From | Andi Kleen <> | Subject | Re: RFC: Network privilege separation. |
| |
On Wed, Jan 07, 2009 at 11:51:08PM -0500, Michael Stone wrote: > In short, I'm trying to provide a general-purpose facility for > > * limiting networking per _process_, not per user, > > * with an api that requires no privilege to exercise,
While it may seem old fashioned the good old suid wrapper is still working well for such things. That assumes you don't want to do that in the middle of a process execution, but that seems like a reasonable restriction.
> * which is suitable for widespread adoption by lots of Unix vendors and > related standards bodies,
Hmm, I suppose RLIMIT_* does not qualify then.
> + when it drop privileges, it becomes unable to acquire new resources > on > its own
That's difficult, for example are you going to disallow fork/exec? If no then the process might still exploit something suid.
Also typically such sandbox schemes want to restrict more system calls (basically using a white list), just in case to protect against unknown kernel holes in the more complex ones.
> + though other processes may still be able to send your process tokens > which give it access to resources which it couldn't open on its own. > > Does this help clarify the causes of my design choices?
It would be probably better if you had a few concrete use cases too (so not just what, but also why)
Anyways, it all sounds like more like it should be done as a special case in a more general sandbox framework to me. Linux already has several ones (e.g. selinux, secure computing, AA out of tree). Perhaps one of them could be adapted to your needs.
> >Why limiting Unix sockets and not e.g. named pipes? > > Named pipes, like non-abstract unix sockets, are manageable through the > filesystem, e.g. by DAC and namespace manipulating tools like bind-mounts
In Linux, at least traditional BSD semantics ignore file system access checks on Unix sockets.
> and > chroots.
There are more IPC mechanisms around too, e.g. sysv message passing or queued signals with payload. You probably need to consider all of those.
-Andi
-- ak@linux.intel.com
| |