[cap-talk] Unix domain sockets and MAC confined processes as (object) capability system?

[rmeijer]

On Linux there are three interesting facilities regarding privilege
separation:

1) Using MAC (SELinux/AppArmor/etc) a process can be functionally cut of
from access
to most of the file-system.
2) Using UID based firewall rules, a process running under a particular
UID can be functionally
cut of from initiating or directly accepting any network traffic.
3) Using Unix domain sockets, open file, network connection handles and
importantly other Unix
domain sockets can be handed over between processes.

If you combine these three techniques and keep the code-base of
individual processes relatively small, you will have a privilege
separated system that, if you consider a small-code-base process to be a
coarse grained object, and if you consider the Unix domain sockets,
network connections and open file handles to be capabilities, has
approximately the same semantic structure that a small program in an
object capability language has.

As such I've considered this type of privilege separation to effectively
be not just a capability system but actually an object-capability
system.

Given some recent discussions however, I've found that either I'm wrong
about this assertion, or that this view is simply confusing to people as
multiple capability people seem to strongly be opposed to the idea that
file handles on Unix could be capabilities at all, let alone object
capabilities.

My questions thus are:

* Are there any reasons why a privilege separated program that uses a
combination of above
techniques would not qualify as a capability system?
* Are there reasons why open network connections, file handles and Unix
domain sockets would
not qualify as (object) capabilities?

Kind regards,

Rob
_______________________________________________
cap-talk mailing list
cap-...@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk

[Bill Frantz]

On 2/19/16 at 11:04 PM, rme...@xs4all.nl (rmeijer) wrote:

>On Linux there are three interesting facilities regarding privilege separation:
>
>1) Using MAC (SELinux/AppArmor/etc) a process can be functionally cut of from access
>to most of the file-system.
>2) Using UID based firewall rules, a process running under a particular UID can be functionally
>cut of from initiating or directly accepting any network traffic.
>3) Using Unix domain sockets, open file, network connection handles and importantly other Unix
>domain sockets can be handed over between processes.

I admit that to me, Unix and friends are a black art. I was
convinced, after a long time studying it, that Postfix did
actually implement least privilege under Unix, so I think it can
be done, and I take my hat off to the people who designed that system.

What worries me is what can be done with the ambient privilege
available in Unix. If things can be fenced off well enough, I'm
a fan, although certainly not capable of determining "well
enough" for my self (which remains a worry).

Assuming that indeed Unix programs can be usefully contained,
can we build a system/language/??? which makes all the mechanism
disappear, and all we see is the capability relations? IMHO,
that would be a very useful addition to the list of object
capability systems.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz |"Web security is like medicine - trying to
do good for
408-356-8506 |an evolved body of kludges" - Mark Miller
www.pwpconsult.com |

[Kenton Varda]

On Thu, Feb 18, 2016 at 11:04 PM, rmeijer <rme...@xs4all.nl> wrote:

On Linux there are three interesting facilities regarding privilege separation:

1) Using MAC (SELinux/AppArmor/etc) a process can be functionally cut of from access
   to most of the file-system.
2) Using UID based firewall rules, a process running under a particular UID can be functionally
   cut of from initiating or directly accepting any network traffic.

I'd argue that it's easier, more elegant, and more robust to use Linux's namespaces to achieve these two points. A mount namespace allows you to define a new filesystem tree that can import specific directories from the real one. A network namespace allows you to block network access. You can also prevent the process from seeing other PIDs with a PID namespace (important to prevent it from sending signals), etc.

(This is what sandstorm.io does.)

 

3) Using Unix domain sockets, open file, network connection handles and importantly other Unix
   domain sockets can be handed over between processes.

Passing FDs over unix domain sockets comes pretty close to being capability-based security. The big problem is that a lot of other file descriptor types that you might introduce over a Unix domain socket are not well-designed as object capabilities. For instance:

- A file descriptor for a directory will permit you to open ".." to get to the parent directory an on up to the root. If you're in a mount namespace, but the directory FD is *not* in the mount namespace, it will actually provide full access to the filesystem outside the mount namespace.

- A socket FD can (I think) be re-bound to other addresses at will.

- If /proc is mounted, then you may be able to use it to re-open a file descriptor with different access rights, with the permission check being based on the underlying file's ACL and the caller's UID.

- Most file descriptor types cannot be emulated by another process. E.g. a process cannot create a virtual file that behaves like a disk file (allowing seeking, mmap, etc.). Userspace processes can really only create pipes and sockets.

The Capsicum project is trying to fix a lot of these issues, but adoption into Linux has been slow.

For Sandstorm, our solution is to avoid passing file descriptors across the sandbox boundary, but instead have the app talk to the outside world using Cap'n Proto, which is a true object capability protocol.