What Is Capability-Based Security in an Operating System?
Learn what capability-based security is, how unforgeable tokens replace ACL lookups, with real systems and an interview-ready example.
Expected Interview Answer
Capability-based security is an access control model where a process’s right to perform an operation on an object is represented by an unforgeable token, called a capability, that it must present and possess directly, rather than the OS looking up an identity against a permission list attached to the object.
Instead of asking 'who is this process and what does the object’s permission table say about them' as ACL and permission-bit systems do, a capability system asks 'does this process actually hold a token that grants this specific right on this specific object.' A capability bundles a reference to an object with a set of rights (read, write, invoke) and is protected from forgery by the kernel or hardware — a process cannot manufacture one, only receive it by creation, inheritance, or explicit delegation from another holder. This flips the security model from identity-centric to possession-centric: if you never had the capability handed to you, you structurally cannot access the object, which naturally enforces least privilege because processes only ever hold the exact capabilities they were given, not a broad identity that a lookup table might over-grant. Real systems using this model include seL4's capability-based kernel, the historical Cambridge CAP computer, and modern designs like Google’s Fuchsia (Zircon) and CHERI hardware capabilities; the tradeoff is that revoking a capability that was already delegated onward is harder than editing a single row in an ACL.
- Access follows possession of an unforgeable token, not an identity lookup
- Naturally enforces least privilege — you can only use what you were actually handed
- Delegation is explicit, making capability flow auditable by design
- Removes ambient authority: no implicit access via being a certain user
AI Mentor Explanation
Capability-based security is like a hospitality pass system where the physical wristband itself is your access, not a name on a list: whoever is wearing a valid, unforgeable pavilion wristband gets in, regardless of who they are, and stewards never consult any master guest registry. Wristbands can be handed from one guest to another (delegation), but they cannot be photocopied or faked because of embedded holograms (unforgeable), so possession alone — not identity lookup — is what grants entry.
Step-by-Step Explanation
Step 1
Capability creation
The kernel mints an unforgeable token bundling a reference to an object with a specific set of rights.
Step 2
Delegation
A process holding the capability may explicitly pass a copy (or a restricted subset of it) to another process it trusts.
Step 3
Presentation on access
To perform an operation, a process must present the actual capability token, not merely claim an identity.
Step 4
Kernel verification
The kernel checks the token's authenticity and rights directly, with no object-side permission table lookup involved.
What Interviewer Expects
- Understanding capabilities as unforgeable, possession-based tokens
- Clear contrast with identity-based models like ACLs
- Awareness of how delegation and least privilege naturally fall out of the model
- At least one named real system (seL4, CHERI, Fuchsia/Zircon, CAP computer)
Common Mistakes
- Confusing a capability with an ACL entry that merely names a user
- Thinking capabilities require a central lookup table on every access
- Not knowing that capabilities can be delegated between processes
- Failing to mention that capability revocation is harder than editing an ACL row
Best Answer (HR Friendly)
“Capability-based security flips the usual question from 'who are you and what does the file say you can do' to 'do you actually hold a specific, unforgeable token granting this exact right.' If a program was never handed that token, it structurally cannot touch the resource, which makes it very natural to keep every process limited to only the access it truly needs, since nothing is granted implicitly by identity.”
Code Example
typedef struct {
unsigned long object_id;
unsigned int rights; /* bitmask: READ, WRITE, INVOKE */
unsigned long token; /* kernel-issued, unforgeable */
} capability_t;
int cap_check(capability_t *cap, unsigned long want_object, unsigned int want_rights) {
/* No lookup of "who is this process" happens here at all --
only whether the presented token is valid and grants the rights. */
if (!kernel_token_is_valid(cap->token)) {
return 0; /* forged or revoked capability */
}
if (cap->object_id != want_object) {
return 0;
}
return (cap->rights & want_rights) == want_rights;
}Follow-up Questions
- How does capability revocation work when a capability has already been delegated onward?
- How does a capability-based kernel like seL4 differ from a traditional ACL-based kernel?
- What is ambient authority, and why do capability systems try to eliminate it?
- How do hardware capability architectures like CHERI enforce unforgeability?
MCQ Practice
1. In capability-based security, what determines whether an operation is allowed?
Access in a capability system is granted purely by possessing a valid, unforgeable capability token for that object and right.
2. How does a process typically obtain a new capability?
Capabilities are acquired through kernel-mediated creation, inheritance across process creation, or explicit delegation, never by guessing or forging.
3. What is a key advantage of capability-based security over ACLs for least privilege?
Because access follows possession of specific tokens rather than a broad identity, processes cannot exercise rights they were never explicitly given.
Flash Cards
What is a capability in OS security? — An unforgeable token bundling an object reference with a set of rights, whose possession alone grants access.
Capability model vs ACL model? — Capabilities are possession-based (do you hold the token); ACLs are identity-based (does the list know you).
How is a capability obtained? — Via kernel-mediated creation, inheritance, or explicit delegation from another holder.
Name a real capability-based system. — seL4, CHERI, Google Fuchsia (Zircon), or the historical Cambridge CAP computer.