[COFF] Other OSes?

[Dan Cross]

On Sun, Jul 8, 2018 at 4:31 PM Perry E. Metzger <perry at piermont.com> wrote:

> [snip]
> On Wed, 4 Jul 2018 23:40:36 -0700 Bakul Shah <bakul at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20180708/25ff8ef9/attachment.html>