Capability-Based Security

Capability-Based Security est un modèle d'authorization où l'autorisation d'effectuer une action est représentée par la possession d'un "capability" (token unforgeable) qui à la fois identifie la ressource ET autorise spécifiquement l'opération. Différent de ACL (Access Control Lists où on vérifie qu'un identifié a permission) — capabilities are "bearer tokens" : whoever has it, can use it.

Principe : capability = (resource_id, rights, integrity_proof). Possession = authorization.

Exemples capability-based systems :
(1) **File descriptors UNIX** — handle to opened file = capability ; can be passed between processes via Unix domain sockets ; receiver can use file without re-checking permissions.
(2) **OAuth 2.0 access tokens** — bearer tokens capability-like (whoever has token can access scoped resources).
(3) **JSON Web Tokens (JWT)** signed — capability if encoded permissions.
(4) **Signed URLs** (S3 presigned, Cloud Storage signed URLs) — URL itself = capability with expiry.
(5) **Tahoe-LAFS** distributed filesystem — capability-strings encode read/write access.
(6) **EROS, KeyKOS, seL4** capability-based operating systems — OS-level capabilities for all resources.
(7) **Object capability models** (E language, Pony, Wasmtime) — programming language constructs.
(8) **WebAssembly Component Model** — capability-based imports.

Force vs ACL :
(1) **Least authority natural** — must explicitly grant capability ; no implicit access.
(2) **Composition** — combine capabilities to grant nuanced access.
(3) **Delegation** — pass capability to others (subset rights if attenuable).
(4) **No ambient authority** — process can't access resources it wasn't given capability to.
(5) **Revocation** — revoking capability invalidates all derived copies (challenging in distributed systems).

Faiblesses :
(1) **Token theft** = full access (same problem as bearer tokens) — mitigate avec sender-constraint (DPoP, mTLS) ou short expiry.
(2) **No central authorization point** — harder to audit "who has access to X?".
(3) **Conceptual unfamiliarity** — most developers think ACL/RBAC first.

Modern resurgence : (1) **OAuth/OIDC** — capability mindset ; (2) **Object capabilities WASM** ; (3) **Zero-Trust** philosophy aligned (verify per-action vs perimeter trust) ; (4) **Cryptographic capabilities** (Macaroons — Google research, decentralized authorization).

Macaroons example : create read-only capability, can attach caveats (expire in 1h, only IPs from 10.0.0.0/8) ; receiver verify all caveats hold ; very flexible delegation. Used Discord, Auth0, etc.

Use cases idéaux : (1) decentralized systems (P2P, blockchain) ; (2) cross-organizational sharing (signed URLs) ; (3) microservices passing capabilities downstream ; (4) edge computing without central auth check ; (5) IoT scenarios. Compétences SC-300, CISSP.