Not exactly, from what I can tell. This lets you run an individual process in a host environment, but using fine-grained privilege restrictions, and some judicially inserted virtualization. LXC runs hosts in a complete OS-level virtualized environment, more like its own Linux instance, which is a bit more complete virtualization (not always desired for a single process).
A Solaris / OpenSolaris / Illumos analogy is to compare running a process in a new Zone (which is like a FreeBSD Jail or a Linux LXC/OpenVZ container), versus running a process in an existing Zone but using ppriv(1) to selectively drop privileges usually given to processes by default, such as network access, file read/write, exec, etc. One is in what looks like its own OS instance, while the other is in the parent OS instance but sandboxed. The analogy isn't quite complete because the ppriv(1) approach doesn't lie to processes that try to violate the permissions like Mbox does; instead it just denies their attempts to do something that violates policy (such as opening a file). So, it might cause sandboxed processes to crash, rather than letting them complete with faked completion.
Not really; mbox uses seccomp-bpf to filter system calls, from userland, using unprivileged users. A very ambitious project to build on top of mbox might be an even lighter-weight Docker-alike using userland system call interposition instead of Linux containers.
I'm calling it now - such a project should be called "Mocker".
Actually, this is really a good idea. I hadn't realized that non-root users can't start their own Docker images, which I think could be a killer application. Perhaps if the overhead from something like Mbox is low enough, this could be feasible. As it is, I'm not sure I'm willing to fork over the extra ~20% overhead, just to have my applications running in a sandbox, but this could be a good method to distribute complete environments.
For some applications I would be more than willing to accept 20% overhead in exchange for perfect security. Still better than setting up dummy virtual boxes.
Not sure it is perfect security. There are race conditions with ptrace sandboxes. Have not read the paper yet to see if they mitigate somehow with seccomp.
You might as well give them password-less sudo. Also, why are you changing permissions on the socket at all? The default is 660 which seems perfectly fine to me, if it's currently 666 you just gave everything on your box free root access.
A Solaris / OpenSolaris / Illumos analogy is to compare running a process in a new Zone (which is like a FreeBSD Jail or a Linux LXC/OpenVZ container), versus running a process in an existing Zone but using ppriv(1) to selectively drop privileges usually given to processes by default, such as network access, file read/write, exec, etc. One is in what looks like its own OS instance, while the other is in the parent OS instance but sandboxed. The analogy isn't quite complete because the ppriv(1) approach doesn't lie to processes that try to violate the permissions like Mbox does; instead it just denies their attempts to do something that violates policy (such as opening a file). So, it might cause sandboxed processes to crash, rather than letting them complete with faked completion.