Access control: who or what principals gets access to what resources. In common parlance: ‘if you can show you are who you claim to be, I will give you what you are allowed according to the access control policy.’
OS traditionally implements access control, but has limits on granularity. Classic example is database controls. If database is stored as a file, OS can handle access control only at level of entire file. Access control for specific records in the file requires application-level mechanisms.
Access control often pictured as a matrix of principals as columns, resources as rows
Alice Bob
Resource 1 Y N
Resource 2 Y Y
Capabilities and ACLs
Access control lists or ‘ACLs’ are policy implemented ‘by row’: attaching to each resource the principals that have access to it (like UNIX file permissions). If Alice wants to access Resource 1, the ACL for Resource 1 is checked to see if Alice is in it. ACLs answer ‘who has access to this resource’, and are good for long-term policy.
Capabilities are policy implemented ‘by column’, but really also in some sense independent of the principal: a principal presents an unforgeable ticket granting access to the resource, and the system simply checks the ticket. Capabilities are good for short-term policy, and are flexible. Examples are cryptographic tokens in distributed protocols, object references in languages (object-capabilities security model- most familiar are file descriptors).
Conceptually, the ACL model is identity-based: Alice simply shows up with a password to login. In the ACL model anyone can attempt access. While in the capabilities model, only the possessor of a token can even attempt access- but the corresponding downside to this ‘key as opaque reference’ model is capabilities can be shared, and are difficult to revoke. Can counterbalance partially by token expiration, and generally restricting scope of privileges. Capabilities typically grant access to one specific resource.
For example a common organization service authorization model is ACLs for employees and other services, and capabilities for end-users and services acting on end-users’ behalf.
Another example: login with email and a password is in isolation an ACL, a ‘one-time passcode’ in isolation a capability (in this case, to complete the login). Usually have both together.
Sharing a document: typically can ‘share with anyone given access to a generated link’, or can ‘share within the org’. Former is a capability (in this context called a ‘capability URI’), latter access control. It would seem from this example that capabilities are a poor and over-permissive security model, but the capability-based security model would be to regulate any communication between Alice and Bob as itself a distinct capability.