On Sun, Jul 8, 2018 at 4:31 PM Perry E. Metzger <perry@piermont.com> wrote:
[snip]
On Wed, 4 Jul 2018 23:40:36 -0700 Bakul Shah <bakul@bitblocks.com>
wrote:
> - Capabilities (a number of OSes implemented them -- See Hank
> Levy's book: https://homes.cs.washington.edu/~levy/capabook/

A fascinating resurrection of capabilities in a kind of pleasant
Unixy-way can be found in Robert Watson's "Capsicum" add-ons for
FreeBSD and Linux. I wish it was more widely known about and adopted.

> - Namespaces (plan9)

A good choice I think.

Interestingly, it was in talking with Ben Laurie about a potential security model for Akaros that I realized the correspondence between Plan9-style namespaces and capabilities. Since Akaros had imported a lot of plan9 namespace code, we concluded that we already had the building blocks for a capability-style security model with minimal additional work. I subsequently concluded that Capsicum wasn't strong enough to be complete. By way of example, I refer back to my earlier question about networking. For example, rights(4) on FreeBSD lists CAP_BIND, CAP_CONNECT, CAP_ACCEPT and other socket related capabilities. That's fine for modeling whether a process can make a *system call*, but insufficient for validating the parameters of that system call. Being granted CAP_CONNECT lets me call connect(2), but how do I model a capability for establishing a TCP connection to some restricted set of ports on a restricted set of destination hosts? CAP_BIND let's me call bind(2), but is there some mechanism to represent the capability of only being able to bind(2) to TCP port 12345? I imagine I'd want to make it so that I can restrict the network 5-tuple a particular process can interact with based on some local policy, but Capsicum as it stands seems too coarse-grained for that. Similarly with file open's, etc.

Curiously, though it wasn't specifically designed for it, but it seems like the namespace-style representation of capabilities would be simultaneously more Unix-like and stronger: since the OS only has system calls for interacting with file-like objects (and processes, but ignore those for a moment) in the current namespace, a namespace can be constructed with *exactly* the resources the process can interact with. Given that networking was implemented as a filesystem, one can imagine interposing a proxy filesystem that represents the network stack to a process, but imposes policy restrictions on how the stack is used (e.g., inspecting connect establishment requests and restricting them to a set of 5-tuples, etc).

        - Dan C.