> If so, how would you enable/disable passing capabilities? By having a meta-capability "I can pass capability foo"?
I would first question why you think you need to disable capability passing at all, which was the main thrust of my post [1]. What specific problem are you trying to solve by restricting capability passing?
Perhaps Unix-style 'fork' has some undesirable semantics, but I don't see how restricting capability delegation would solve them. POSIX sandboxes using capabilities have been done a few times, originally KeyKOS and then EROS. Perhaps the most accessible introduction for those coming from a UNIX introduction would be Capsicum [2].
[1] Yes, "kind" classifies capabilities into those that can be passed around without restriction, and those that can't, so I'm questioning the utility of that
> I would first question why you think you need to disable capability passing at all, which was the main thrust of my post [1]. What specific problem are you trying to solve by restricting capability passing?
Right now, my specific problems #1 (resp. #2) is understanding what you (resp ticki) have in mind :)
But I can also think of problems such as:
1/ limiting privilege escalation;
2/ somehow transitively revoking privileges that have been obtained through a compromised process.
Not sure if `Kind` has any effect on either, but I'll spend a few days thinking about these issues. I'd be happy to chat with you if you're interested (I'm Yoric on irc.mozilla.org).
Revocation is a solved problem for pure capabilities [1,2]. Privilege escalation is typically not so important in capability systems because processes run with least privileges. There is a pattern whereby authority can be increased if you're granted a special type of capability -- the operation is called "rights amplification" in capability parlance, but these capabilities are closely held by the trusted base.
Finally, the reason restricting delegation doesn't generally work is that a process can just proxy access to the undelegable capability, which means you haven't actually attentuated authority in any meaningful way. At best, you've merely reduced the bandwidth, so overall performance suffers, and you've also sacrificed compositional reasoning.
Anyway, that's why I initially asked for any design documents for Redox's capability system, so I encourage ticki and any others working on this to write a rough draft of the ideas. I know plenty of capability people who would happily provide feedback.
I would first question why you think you need to disable capability passing at all, which was the main thrust of my post [1]. What specific problem are you trying to solve by restricting capability passing?
Perhaps Unix-style 'fork' has some undesirable semantics, but I don't see how restricting capability delegation would solve them. POSIX sandboxes using capabilities have been done a few times, originally KeyKOS and then EROS. Perhaps the most accessible introduction for those coming from a UNIX introduction would be Capsicum [2].
[1] Yes, "kind" classifies capabilities into those that can be passed around without restriction, and those that can't, so I'm questioning the utility of that
[2] https://www.usenix.org/legacy/event/sec10/tech/full_papers/W...