Hacker News Reader

Comment by Ericson2314 | Hacker News Reader

Plan 9 made a number of improvements, but while "everything is a file" is an improvement, "everything is a file descriptor" think is better. namespaces aside, files as global variables, while file descriptors are local variables. It is much more easy to make an interface that "naturally" makes it easy to abide by https://en.wikipedia.org/wiki/Principle_of_least_privilege with local variables.

Unix < Plan 9 < Capiscum-like designs, for me.

(Of course, if Capsicum is "capability-based security for Unix", maybe a "capability-based security for Plan 9" is better than that. :))

View on HN

Plan9 in fact uses file descriptors all over the place, including accessing synthetic or real filesystems (which are really namespaces). In fact the only "globals" are the #<dev> devices.

IMHO you're better off starting with plan9 concepts + pure capabilities (KeyKOS as opposed to Capsicum). It would not enough to have a clean architecture unless a) it matches or improves upon performance and b) there is a way to run existing Unix software via some adapter layer or library or monitor.

I suspect if you try to "reform" unix, there will be a lot of recidivism :-)

capros. keykos is so 1980.

i miss when osnews was still decent.

> recidivism

Yes, it is not enough to just add yet more interfaces. Using personalities to ban the use of deprecated systemcalls is an essential follow-up step. Fostering experimental kennels which don't bother to support the old interfaces at all is another.

Funnily enough, Plan 9 implements a kind of proto-capability security environment given how namespaces work. You have to squint a bit at it, but the semantics are mostly there.

Of particular note, the maxim "you can't attack what you can't see" is reasonably well represented. Whenever you rfork() a new process, you can shed whatever parts of the new namespace are irrelevant before ultimately exec()ing, and barring certain exceptions, the new image running in that child process can't get them back on its own. There are ways to augment other namespaces with mounts that are reminiscent of delegating a capability to another process. There are also ways to lock down a process to prevent it from changing its namespace, which is roughly congruent to blocking a process from receiving delegated capabilities.

I think Capsicum is a good start, but it does not have revocation built in — which I think is essential for a system in which capabilities can be held by long-lived apps or services. There are approaches where revocation is expressed as a network of capabilities, but that just makes using it more complex.

Also, revocation should be cascading: revoking also derived capabilities. The system would need to store a delegation-tree. Then there's the issue processor time for cascading revocation, which could depend on the size of the tree.

Yes that would be good, but I'm OK delaying it. People are used to capabilities without revocation from functional programming, Rust, WASI, etc., and don't mind so much in that context.

(Well, weak references allow revocation, but they are relatively rare.)

Yes, interprocess vs intraprocess is different, but the above makes me at least think there is some juice and first exposing the lower-hanging fruit that people are already familiar with and seem to like, and then using the success of that to motivate/fund revocation.

Reply on news.ycombinator.com