Access Control for Security Engineers: ACLs vs Capabilities
The access control matrix — subjects (rows) × objects (columns) × permissions — is covered in depth in the Operating Systems notes, along with a full worked matrix-construction example. This note assumes you know that material and focuses on the security-engineering perspective: when and why you choose each representation as a system designer, and how the choice interacts with threat modelling and authentication.
Quick Résumé
| ACLs (column-centric) | Capabilities (row-centric) | |
|---|---|---|
| Storage | Each object lists which subjects may access it, with which rights | Each subject holds unforgeable tokens granting specific rights to specific objects |
| Check access | Scan the object’s ACL | Present the capability |
| ”What can this user do?” | Hard — scan every object | Easy — inspect the subject’s capability set |
| ”Who can access this file?” | Easy — read the file’s ACL | Hard — scan every subject’s capabilities |
| Revocation | Easy — modify the object’s ACL | Hard — must track and invalidate all copies; cascading delegation makes this complex |
| Delegation | Awkward — owner must update the ACL | Natural — pass a (possibly restricted) copy of the capability |
Access Control and STRIDE
The choice between ACLs and capabilities directly affects which STRIDE threats are easier or harder to defend against:
Elevation of Privilege
ACLs centralise permission in the object. A single misconfigured ACL entry can leak read access to unauthorised parties — but it is a single, auditable point of failure. Auditing ACLs is straightforward: for a given object, its ACL is contained in one place; you can verify exactly who has access. A misconfiguration is detectable by a compliance script that scans object ACLs.
Capabilities distribute permission across subjects. There is no single place to audit “who can access this file.” A leaked capability — e.g. a file descriptor passed accidentally to an unauthorised process, or a capability token stolen from a log file — grants access that is hard to detect centrally. Misuse is harder to trace and harder to revoke — you must find every copy of the leaked capability.
Spoofing and Repudiation
ACLs typically tie access to an identity (a username, a group membership). The system checks who you claim to be against the ACL. This makes authentication — proving identity — a prerequisite for access control. A compromised password (Spoofing) grants the attacker all the ACL-based permissions of that user.
Capabilities are identity-agnostic: possession of the token is the proof. The system does not need to know who you are, only that you hold a valid capability. This decouples authentication from authorisation — a useful property in distributed systems where subjects may not share an identity namespace.
Choosing an Approach for System Design
When ACLs are natural
- The system has a central authority that manages users and permissions (a corporate file server, a cloud platform with IAM, a single-tenant web application).
- Auditability matters more than agility — you need to answer “who can access this customer’s data?” for GDPR compliance without scanning every user.
- The set of subjects changes frequently but the set of objects and their access policies is relatively stable. Adding and removing users is easy when each object independently lists its authorised subjects.
- The personal laptop case (see OS notes): millions of files, a handful of users. Every file carries a tiny owner/group/other triple.
When capabilities are natural
- The system is decentralised with no central authority — e.g. the 2025 Tripos federated social network, where servers are run by independent operators and identities are not globally managed.
- Delegation is a core use case — a user needs to grant a third-party service access to a specific resource without involving an administrator.
- Minimising the trusted computing base matters — a kernel can enforce that capabilities are unforgeable (held in kernel space, accessed via opaque handles) without any user-space policy engine.
- Performance under high throughput — checking a presented capability is a faster operation than scanning an ACL for many access patterns, because the capability already encodes the exact permission.
The UNIX hybrid
UNIX provides a practical case study, also covered in the OS notes: ACLs at open() time (the kernel checks owner/group/other bits against the process’s UID and GID), then capabilities for the open file (the returned file descriptor is unforgeable and can be passed across fork()). This hybrid gives you auditable initial access with fast, delegable ongoing access.
Access Control in the 2025 Tripos Context
The 2025 Paper 2 Question 5(b) asks about introducing public-key authentication to a decentralised social network. The access control model of that system is implicit but relevant:
- Under password authentication, each server independently manages its own ACLs. Cross-server trust — verifying that a post attributed to Server A’s user is genuine — has no cryptographic basis. Server B must trust Server A’s word (cf. STRIDE Spoofing).
- Under public-key authentication with signed posts, the signed post itself acts as a form of capability — a cryptographically verifiable token proving that the author possessed a specific private key at signing time. Any receiving server can independently verify the token. This is capability-style decentralised trust: no central identity provider needed.
The full authentication discussion is covered in detail in the password vs public-key note.
Expected Learning
- Recall the ACL-vs-capability trade-offs from the OS module.
- Explain how the access control model connects to STRIDE threats (Elevation of Privilege, Spoofing).
- Justify a choice of ACLs or capabilities for a given system scenario, citing the specific security properties that matter: auditability, delegation, centralisation, and identity management.
- Explain how signed posts in a federated system function as capabilities for cross-server content verification.
Past Paper Questions
The access matrix construction and ACL-vs-capabilities comparison is assessed on the Operating Systems paper (2025 Q3a-b, 2019 Q4c). The SWSecEng paper expects you to deploy this knowledge in security-focused scenarios — e.g. the 2025 Q5(b) authentication question, where understanding capability-style decentralised trust strengthens your argument for public-key signing in a federated system. For the full matrix-construction worked example, see the OS module.