6 Capability-Based Access Control

6.1.1 The Key-in-Hand View

• Unforgeable token: Possession grants the right, so an untrusted holder must not be able to forge it — protect it through the runtime or a cryptographic signature or MAC.
• Object plus rights: A capability designates a specific object and the operations allowed on it, not a broad identity label.
• Delegable, but sticky: A holder can pass a capability (or a narrower subset) onward. The trade-off is that revoking it is typically harder than deleting a list entry (a kernel can track derived copies; a copied bearer token needs expiry or a denylist).

6.1.2 Everyday IoT Examples

Work from the simplest case toward the broader design consequence. First, a valet key for a car is a capability subset: it can typically drive and park but not open the trunk or the glovebox. Next, a shareable, time-limited code that opens only the front door — and nothing else — can act as a bearer capability if it is unforgeable and checked for that door. Finally, “This token lets the holder read sensor 42 until noon” describes a capability if the token is unforgeable and names that sensor; “this user has an admin role” still needs the role’s permissions checked.

6.1.3 Overview Knowledge Check

If you can explain why authority travels with a held token, you have the core idea. Continue to Practitioner to represent capabilities, compose them, and choose when the key-in-hand pattern is better than another role.

6.2.1 Base, Ceiling, and Elevation

A robust design distinguishes a user’s or device’s base capabilities, granted by default, from its maximum capabilities, an absolute ceiling it can never exceed even when temporarily elevated. A canElevate flag controls whether elevation is allowed at all. When a sensitive action is needed — an emergency shutdown, a firmware write — the holder elevates specific capabilities for a short, time-boxed window, gated by extra authorization such as a supervisor’s approval. This is cleaner than swapping roles or minting a temporary admin account, because (if the grants are logged) the audit trail shows exactly which extra rights were used, when, and under whose approval.

6.2.2 Choosing Among RBAC, Capabilities, and ABAC

6.2.3 Worked Example: Shift Reassignment Without Role Explosion

Picture an industrial control room where operators rotate across shifts and certification levels. With pure RBAC, every combination tends to spawn its own role — a day-shift level-three role, a night-shift level-three role, and so on — until the role list is unmanageable. A capability design could instead issue an operator narrowly scoped, time-limited authority for a named control, leaving the resource definitions untouched. Emergency shutdown sits at the operator’s ceiling and requires a second person’s approval. The example avoids a combinatorial role table; RBAC with temporal extensions, or ABAC, could also handle changing shifts.

6.2.4 Capabilities in the Physical World

Digital vehicle keys illustrate narrower rights. A shared or valet key is an attenuated capability: for example, it can drive but cannot open the trunk or exceed a set speed. Early keyless-entry systems relied on weak proprietary ciphers that security researchers were able to clone. A digital key must resist forgery, but a bearer credential can still be copied or stolen, so its storage, transfer, and revocation also matter.

6.2.5 Practitioner Knowledge Check

If you can represent rights as flags, gate elevation by a ceiling, and choose the model by need, you can stop here. Continue to Under the Hood for unforgeability, delegation, and the revocation trade-off.

6.3.1 The Bit Mechanics

When the rights within a capability are represented as flags, each permission is an independent bit position, not a step in a ladder — setting the fourth bit does not imply the first three. Composite rights sets are built by OR-ing flags together. An access check is conjunctive: the granted set must contain every required bit, which is the bitwise test (granted & required) == required. A rights set can fit in a small integer on a microcontroller; the complete capability still needs a protected object reference or authenticated token.

6.3.2 Unforgeability Is the Whole Game

Because possession grants authority, a capability is only safe if an untrusted holder cannot forge or alter it. Two established approaches are a protected reference, mediated by a runtime or kernel, and a cryptographically authenticated token. Unix file descriptors and seL4 kernel capabilities illustrate protected references; a process can pass a descriptor to another process as a delegation. Macaroons use chained MACs, and a signed or MAC-protected, time-limited URL can also carry authority if it names the resource and permitted operation. The verifier must check the protection, scope, and any expiry. A plain client-editable string of flags is not an unforgeable capability.

6.3.3 Where the Rights Live, and the Revocation Trade-Off

A central design question is whether the rights travel with the client or stay on the server. If you place permission flags in a client-held bearer token, its claims must be cryptographically authenticated — otherwise the client edits its own permissions. Without a live revocation check, a valid token can be used until it expires; RFC 6750 §5.3 recommends short-lived bearer tokens, while RFC 7662 describes token introspection for checking current state. If instead you hand the client an opaque session identifier and keep its rights server-side, revocation can take effect on the next checked request, but you have moved back toward an ACL-style lookup. Kernel-managed capabilities have their own revocation mechanisms, such as seL4’s revocation of derived capabilities. Choose short lifetimes plus a denylist or introspection when authority lives client-side; choose server-side rights when you need revocation on the next request.

6.3.4 Delegation, the Confused Deputy, and Ambient Authority

Delegation is a defining strength: a holder can pass a capability, or an attenuated subset of it, to another principal without a central issuer approving each handoff. Capabilities also resist the confused-deputy problem, in which a privileged program is tricked into misusing its broad authority on an object an attacker names. Because a capability bundles the object designation with the authority, the caller must supply the capability for the specific object, provided the deputy uses only the caller-supplied capability for that operation, so a deputy cannot be steered onto something it was not given. The danger to manage is the opposite: ambient authority, where capabilities are inherited automatically and broadly. Linux CAP_SYS_ADMIN is a broad process privilege, not an object capability like a seL4 reference, and is close to full root. Grant the narrowest capability explicitly rather than relying on inherited power.

6.3.5 Audit as Categorized Events

A capability system should record categorized audit events — access attempted versus granted, elevation requested, and denials — rather than flat log lines. Categorized events let monitoring raise alerts automatically (a burst of denied elevations is a probing signal) and make compliance forensics tractable.

6.3.6 Mechanisms and Failure Modes

6.3.7 Common Pitfalls

• Unsigned capability flags in client tokens. If the token is not cryptographically protected, the client simply forges its own rights.
• Assuming bearer tokens revoke instantly. A locally validated bearer token can remain usable until expiry unless the verifier checks revocation state.
• Over-broad ambient authority. A broad process privilege such as Linux CAP_SYS_ADMIN can defeat least authority when inherited or granted unnecessarily.
• Treating flags as a hierarchy. Bits are independent; one capability does not imply the ones below it.
• No revocation path at all. Without revocation, a capability system can be weaker than a simple list; define expiry, revocation, or both and test the delay.

6.3.8 Under-the-Hood Knowledge Check

At this depth, a capability is a precise, held authority that is only as good as its unforgeability and its revocation story. Rights within a capability may use independent flags; protect the complete token by the runtime or by cryptography, delegate by narrowing where supported, and choose how the system will revoke authority. A trustworthy review checks that forged tokens are rejected, that delegation cannot widen rights, and that revocation actually works.