You're missing the problem. With OS/object capabilities, you'd want to revoke only some (and those derived from them), and keep the rest in place. Otherwise they would not be a viable alternative to ACLs.

For pointers-as-capabilities, and version counter as protection against use-after-free, you can't assign it or the object ID too many bits because you don't want to make the size of pointers unwieldy. I've read articles of such systems that use random numbers or encrypted counters to get more randomness but at the end of the day, the safety is still only probabilistic.

▲

naasking 15 hours ago | parent [-]

> Otherwise it would not be a viable alternative to ACLs.

I just want to point out that this is vastly overblown IMO. Typical ACL systems are just organized differently than capability systems that follow POLA. In the former, permissions to a number of objects are widely shared across many different subjects, and so fine-grained grant and revocation for subjects seem natural. It thus also seems natural to think that you will need fine-grained revocation in a capability system, but that's typically not true, because there is virtually no system-wide sharing of any objects in comparable fashion to ACL systems.

In POLA and capability systems, any given object is almost always only reachable by one or two other objects, and of course this must be the case because otherwise it wouldn't be POLA! The need for fine-grained revocation is thus practically nil, and for those rare occasions that you do want some kind of fine-grained revocation, proxy and membrane patterns enable this.

> It is also not "solved" problem for capabilities-as-pointers.

I'm not clear on what you think isn't solved exactly. KeyKOS solved this issue in the 1970s.

> I've read articles of systems using random numbers or an encrypted counter to get more randomness but at the end of the day, the safety is still only probabilistic.

To be clear, cryptographic capabilities are not the same as object capabilities.

▲

Findecanor 14 hours ago | parent [-]

The counter in a pointer is still a kind of key, even if not cryptographic. What I mean is the risk of hitting the limit of number of available counter bits.

Some approaches on this take the probabilistic route and reuse counter values. Others invalidate the object ID when the counter wraps. I've myself designed a system that did the latter, but I think that was viable in that case only because the churn was expected to be extremely low. But for arbitrary pointers in arbitrary programs you can not make such an assumption.

	▲	naasking 7 hours ago \| parent [-]
		> What I mean is the risk of hitting the limit of number of available counter bits. I think this is vanishingly unlikely in a system like EROS/CapROS. As I said, revocations in such a system are very rare, and the version number is 32-bits. This system is checkpointed and so object IDs and their versions can be garbage collected during the checkpoint.