Security and access control

Prevents the confused deputy problem and enforces least‑privilege by delegating authority through transferable, unforgeable references.

Designing sandboxed plugins, implementing inter‑process communication with least privilege, building secure object‑oriented systems where objects hold only the capabilities they need.

Operating system kernels, capability‑secure languages (e.g., E, Joe‑E), microkernel systems, secure cloud function platforms, and any system applying the principle of least privilege.

capability = make_capability(resource, permissions) result = use_capability(capability, action)

make_capability(...); use_capability(...)

resource: object to protect; permissions: list of allowed operations (e.g., ['read', 'write']); capability: unforgeable token representing the delegated authority; action: specific operation to invoke on the resource.

• principle of least privilege
• access control lists
• object-capability programming
• sandboxing
• capability revocation

• ACL‑based security
• role‑based access control (RBAC)
• mandatory access control (MAC)

Treating capabilities as guessable IDs or pointers, leaking capabilities to unintended code, confusing capabilities with simple references, assuming capabilities can be forged or guessed.

Access Control Lists (ACLs) – check identity against a list; capabilities – unforgeable token itself grants authority. Role‑Based Access Control (RBAC) – permissions tied to roles; capabilities – permissions tied to specific object references.

Coming from C/Java: may think security is about checking user IDs or roles; need to shift mindset to unforgeable tokens that cannot be guessed or forged.

• principle of least privilege
• access control lists
• role-based access control
• object-capability programming

Capabilities must be kept secret; if leaked, the holder gains the delegated authority. They add minimal runtime overhead but require careful design to avoid accidental sharing. Not all legacy APIs map cleanly to capability interfaces.

Eliminates the confused deputy problem, enforces least privilege by construction, and simplifies security reasoning by making authority explicit in object references.

Think of a key that opens exactly one door – you can't duplicate it without the original.

Implementations must ensure capabilities cannot be guessed or forged and that revocation mechanisms are in place to prevent stale authority.

Adopt an object‑capability language (e.g., E, Joe‑E) or runtime that enforces capability safety at the language level.