Subjects, objects, permissions
Access control models almost always come down to three nouns:
- Subjects: who is acting (users, services, processes).
- Objects: what they are acting on (files, sockets, devices, database rows).
- Permissions: which actions are allowed (read, write, execute, delete, configure).
The system's job is to consult a rule book at every operation and say yes or no.
Unix permissions, in five seconds
The classic Unix model is simple: every file has an owner, a group, and three sets of
permissions (read, write, execute) for owner / group / everyone else. That's the
rwxr-xr-- string you see in ls -l.
It's small enough to fit in your head and big enough to express most everyday needs. It fails when you want to give Alice read access to a file her group can't see, or give Bob write access without giving him the owner role. That's what ACLs are for.
ACLs and roles
An Access Control List attaches a longer list of (subject, permission) pairs to each
object. Windows uses ACLs natively; Linux supports them as an extension (setfacl).
More expressive, more configurable, more places for a mistake to hide.
At scale, listing every user against every object becomes unmanageable. The fix is Role-Based Access Control: users are assigned roles (admin, billing, support), and roles get permissions. Most enterprise systems and cloud IAM platforms work this way.
Capabilities: a different shape
ACLs answer the question "who may do X to this object?". A capability flips that around: it's a token you hold that grants the right to perform some operation. To act, you present the token; no global lookup is needed.
Capabilities are everywhere even if the name isn't. A signed AWS pre-signed URL is a
capability. A file descriptor in Unix is a capability. Linux's capabilities(7)
feature splits root's superpowers into named pieces you can hand out individually
(CAP_NET_RAW, CAP_SYS_TIME, etc.).
Sandboxes
A sandbox restricts what a process can do regardless of what the file permissions say. Even if a sandboxed process runs as your user, it can't open random files, can't make arbitrary network connections, can't spawn other processes.
Familiar examples:
- Browser tab processes can't read your filesystem.
- iOS and Android apps live in per-app sandboxes by default.
- Linux containers (using namespaces and cgroups) sandbox whole programs.
- macOS's App Sandbox confines App Store apps.
Defense in depth
Permissions, ACLs, roles, and sandboxes don't replace each other. Modern systems layer them: a process runs as a low-privilege user, in a sandbox, with a small set of capabilities, and the files it can touch have tight ACLs. Several have to fail at once for an attacker to win.
The principle of least privilege
The guiding rule: every subject should have only the permissions it needs to do its job, only for as long as it needs them. Apply it everywhere:
- Don't run servers as root.
- Give the build pipeline write access to one bucket, not the whole account.
- Make admin accounts separate from daily-use accounts.
- Use just-in-time elevation rather than standing admin.
It's simple to state and hard to live. Defaults tend toward more access than needed, because that's the friction-free path. Reining that in is most of what access-control work actually is.