[staticassertion]

What you're referring to is how operating systems maintain the integrity of capabilities. This is addressed directly in 'Capability Based Computer Systems'. I would direct you to chapter 1 section 1.1.

> A capability thus provides addressing and access rights to an object.

> a program cannot access an object unless its capability list contains a suitably privileged capability for the object.

> Capability system integrity is usually maintained by prohibiting direct program modification of the capability list. The capability list is modified only by the operating system or the hardware.

> Thus, a program can execute direct control over the movement of capabilities and can share capabilities, and therefore, objects, with other programs and users.

You can think of capabilities lists as kernel managed namespaces if you'd like. Maybe that would help clear things up.

[monocasa]

In these non crypto enforced capability systems, you don't have any control over other processes' names for resources addressed through capabilities is the point I'm attempting to get across.

Crypto backed capabilities that merge the token with the capability itself are one morph of capability based systems, but that's not the scheme being described here. Leaking the name of a capability (the offset in the cap table) does not leak the capability itself in these TCB schemes. Capabilities are still communicable in these TCB schemes because they're explicitly supported in the IPC mechanisms like SCM_RIGHTS or seL4_Send along side normal data. The token naming a capability then is a per process concept and you can clone an identical capability into several tokens in the same cap table, unlike the crypto enforced scheme which are basically content addressed storage for a secret representing a capability.

[throwaway894345]

Semantics aside, is it accurate to say that schemes where the capability is represented as a signed token require care and diligence to mitigate leaks, and schemes where the capability is represented as a table entry (mapping a user/process to a permission) don't require any meaningful care/diligence?

[Rusky]

Yes, that's the idea.

Though, it is still worth thinking about how someone might accidentally leak a table-based capability via API misuse. For example, if table entries are reused over time you might get a sort of use-after-free situation where you mean to share an old capability but accidentally share the new one that replaced it.