[COFF] Other OSes?

[bakul at bitblocks.com (Bakul Shah)]

On Sun, 08 Jul 2018 22:44:23 -0400 Dan Cross <crossd at gmail.com> wrote:
Dan Cross writes:
>
> 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.

I tend to think they are orthogonal.  Namspaces map names to
objects -- they control what objects you can see.
Capabilities control what you can do with such an object. Cap
operations such as revoke, grant, attenunating rights
(subsetting the allowed ops) don't translate to namespaces.

A cap is much like a file descriptor but it doesn't have to be
limited to just open files or directories.

As an example, a client make invoke "read(fd, buffer, count)"
or "write(fd, buffer, count)". This call may be serviced by a
remote file server. Here "buffer" would be a cap on a memory
range within the client process -- we don't want the server to
have any more access to client's memory. When the fileserver
is ready to read or write, it has to securely arrange data
transfer to/from this memory range[1].

You can even think of a cap as a "promise" -- you can perform
certain operations in future as opposed to right now. [Rather
than read from memory and send the data along with the write()
call, the server can use the buffer cap in future. The file
server in turn can pass on the buffer cap to a storage server,
there by reducing latency and saving a copy or two]

>                              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.

The point of my original comment was that if capabilities were
integral to a system (as opposed to being an add-on like
Capsicum) a much simpler Unix might've emerged. 

[1] In the old days we used copyin/copyout for this sort of
data transfer between a user process address space and the
kernel. This is analogous.