I'm no Windows expert, so I didn't know that windows handles were used as security primitives.
I thought they were just a bit like file-descriptors or X11 window ids, or indeed pointers. Such handles do have a kind of role in authorization: once a process has convinced the system to give it some resource, then the (handle, processid) pair is all the system needs to check access.
However you typically gain the handle through something like `open()`, i.e. an ACLed request for a named resource. But with true capabilities you just inherit authorisation from some other capability -- possibly one granted to you by a different process.
That said, the difference from existing systems might be small. Namespaces are really useful, and are probably here to stay. But as long as things can be accessed by names, the access will need to be controlled by something like an ACL.
> Namespaces are really useful, and are probably here to stay. But as long as things can be accessed by names, the access will need to be controlled by something like an ACL.
Not necessarily. If your system supports first-class namespaces, then you can just build a namespace consisting of only the objects to which a program should have access. No need for any further access control.
A file open dialog from a program is simply the program's request for you to map a file into its namespace.
>Not necessarily. If your system supports first-class namespaces, then you can just build a namespace consisting of only the objects to which a program should have access. No need for any further access control.
Unfortunately this is usually quite heavyweight. In Unix-like systems, and in Plan 9, the canonical way to do this is to implement a filesystem. "Filesystem" is the universal IPC layer. But implementing a filesystem usually takes quite a lot of effort.
Do you know of any systems where this can be done easily enough for it to be used ubiquitously?
One would much prefer to just put together a hierarchy of objects at the language level and automatically expose it... or something like that anyway.
> "Filesystem" is the universal IPC layer. But implementing a filesystem usually takes quite a lot of effort.
It needn't be. A file system is just a set of nested hashtables. The complexity of traditional file systems comes from the durable representation, but that isn't necessarily needed for first-class namespaces. You can just serialize and deserialize a namespace as needed on top of an ordinary file system.
> Do you know of any systems where this can be done easily enough for it to be used ubiquitously?
Plan 9 obviously. The Plash capability secure shell [1]. There are probably a couple of others, but not too many overall.
I explicitly mentioned Plan 9. Plan 9 doesn't do anything to make it fundamentally easier to write a filesystem, it just takes the (wise) approach of standardizing a simple filesystem protocol. (Which is a big help practically of course.) Nevertheless, actually implementing that protocol is still difficult. While it would be nice to represent a filesystem as a nested hashtable, 9P doesn't give you that for free: you need to keep track of fids you hand out.
Plash uses capabilities aggressively and only gives subprocesses access to what they need to access. But it doesn't make it any easier to write new applications which construct namespaces and proxy access.
Hmm, that sounds a bit awkward -- every capability on the system would, at least conceptually need a separate copy of the pruned name-tree. There might be good ways of implementing that, but it's not obvious.
On the other hand, I can see how capabilities would mix with ACLed namespaces to improve security. Essentially it would define the semantics of things like cgroups and chroot jails.
In fact sometimes I think that mainstream virtualisation is slowly reinventing -- in an incremental way -- what various alternative OSes advocated in a radical way. E.g. Linux cgroups and "one process per container" sounds quite a lot like Plan9's per-process view of the system.
> Hmm, that sounds a bit awkward -- every capability on the system would, at least conceptually need a separate copy of the pruned name-tree.
First-class namespaces are an implmentation of capabilities. You wouldn't necessarily need capabilities on top of that. You'd pass around namespaces or perform namespace mappings to grant or revoke authorities.
> On the other hand, I can see how capabilities would mix with ACLed namespaces to improve security.
You can use ACLs to implement capabilities [1], which the capability folks did with Windows XP as a proof of concept with a modern OS [2] (I don't know why Microsoft didn't just adopt Polaris to be frank). But in general you shouldn't use ACLs to try augment capabilities. They restrict the class of expressible security policies without actually adding security (and in fact, they introduce insecurity).
I thought they were just a bit like file-descriptors or X11 window ids, or indeed pointers. Such handles do have a kind of role in authorization: once a process has convinced the system to give it some resource, then the (handle, processid) pair is all the system needs to check access.
However you typically gain the handle through something like `open()`, i.e. an ACLed request for a named resource. But with true capabilities you just inherit authorisation from some other capability -- possibly one granted to you by a different process.
That said, the difference from existing systems might be small. Namespaces are really useful, and are probably here to stay. But as long as things can be accessed by names, the access will need to be controlled by something like an ACL.