Who decides, and the matrix that records it

Four words that are constantly confused

Access control is one function in a chain of four, and an answer that blurs them loses its framing before it starts.

• Authentication asks whether the credentials you presented are valid. It decides whether you get in at all.
• Authorization is the granting of a right — the decision that this principal is trusted for this purpose. It happens once, in advance, and its result is written into an authorization database.
• Access control mediates each individual request against that database, after you are already in.
• Audit is an independent review of the records and activity, and its independence is the point: the party being reviewed does not run the review.

The function is also distributed. The operating system enforces some of it, the DBMS enforces a finer-grained slice of it, add-on packages and the firewall enforce the rest. No single component is "the" access control system, which is exactly why a file that the OS protects can still be gutted by something the OS never sees (you will watch that happen in the next lesson).

The four policy categories, sorted by who sets the rule

The categories are not sorted by strictness, and they are not mutually exclusive — one system routinely runs several for different classes of resource.

• Discretionary access control (DAC) decides on the identity of the requestor and on rules saying what that identity may do. It is discretionary because an entity holding a right may pass that right on of its own volition. That single clause is the whole definition.
• Mandatory access control (MAC) compares an object's classification against a subject's clearance. It is mandatory because a cleared subject may not extend that access to anyone else, no matter how much it wants to.
• Role-based access control (RBAC) decides on the roles a user holds, where a role is a job function inside the organisation.
• Attribute-based access control (ABAC) computes the decision from attributes of the subject, the object and the environment.

DAC and MAC are told apart by whose volition controls propagation, not by how strict they look. A brutally locked-down UNIX box is still DAC, because the owner of a file can chmod it open to the world tomorrow. A permissive MAC policy is still MAC, because no subject inside it can widen its own grant.

Subjects, objects, rights

A subject is generally a process acting on a user's behalf and carrying that user's rights — not the human. That distinction is why a compromised process is a catastrophe: it holds everything the user held. Subjects fall into three classes: owner, group, world.

An object is any resource being controlled, at whatever granularity the designer chose — the choice is a straight security-versus-complexity trade-off.

Two of the rights carry inclusions that examiners love: read includes copying and printing, and write includes read. Search — listing a directory — is a right in its own right, and the next lesson turns on it.

The access matrix, and the three ways to store it

Put the subjects down the side and the objects across the top, and the cell says what that subject may do to that object. Here is the one this lesson works with: three subjects, four objects.

Real matrices are overwhelmingly sparse, so nobody stores the grid. There are exactly three ways to decompose it, and they are the same data:

1. Access control list (ACL) — slice it by column. One list per object, naming the subjects and what each may do. The ACL of payroll.db is alice: read · bob: read, write, own · svc_backup: read. Cheap to answer "who can touch this file?"; expensive to answer "what can bob touch?", because you must walk every object in the system.
2. Capability ticket — slice it by row. One ticket per subject, naming the objects it may reach. svc_backup's capability list is roster.csv: read · payroll.db: read · audit.log: read, write, own. The costs are exactly inverted. Because tickets are dispersed — held by the subject, not by the resource — they must be unforgeable: kept inside the OS, or carrying a large random token or a cryptographic tag the resource verifies. That last option is what makes capabilities workable across a network.
3. Authorization table — one row per (subject, right, object) triple. It dissolves the choice: sort by subject and you have capabilities; sort by object and you have an ACL. Our matrix has 17 such triples.

A row of the matrix has a second name worth knowing: a protection domain, a set of objects plus the rights to them. Decoupling a domain from a user is how you run a process with a subset of the invoking user's rights — a sandbox, or a per-request server worker. The goal of least privilege is to minimise the rights held at any one moment, not the rights a user possesses overall.

Bell–LaPadula: the same matrix under a mandatory policy

Now label things. Every subject gets a clearance and every object gets a classification, drawn from an ordered hierarchy — unclassified < confidential < secret < top secret — optionally with compartments. Subjects are cleared; objects are classified. Swapping those two verbs in an exam answer is a giveaway.

BLP defines four access modes, and two of them are counterintuitive: read is read-only, append is write-only with no read, write is read and write, and execute is neither.

The model has three properties:

• Simple security property — no read up. A subject may read an object only at or below its own clearance.
• \*-property — no write down. A subject may write to an object only at or above its own level.
• Discretionary security property. Ordinary discretionary grants still apply on top — but they are always constrained by the mandatory rules. Site policy overrides the owner's discretion; no access is permitted that fails either of the first two.

Worked example. Take our svc_backup subject and clear it at confidential. Label roster.csv unclassified, payroll.db confidential and audit.log secret. Four requests:

1. Read roster.csv (unclassified). Reading down — allowed.
2. Read audit.log (secret). Reading up — denied by simple security.
3. Write audit.log (secret). Writing up — allowed, and it feels wrong to everyone the first time.
4. Write roster.csv (unclassified). Writing down — denied by the \*-property.

Request 3 is why BLP defines append: a low subject can drop a report into a high container without being able to read what is already in it. Request 4 is the rule that carries the whole model's purpose, and the callout below explains why.

BLP's two well-known failures are worth a sentence each, because knowing them is what separates a full-mark answer from a definition. It has no downgrade provision — real multilevel systems do need legitimate high-to-low flows, and BLP supplies no mechanism, so production systems bolt on a controlled, monitored declassification process. And it suffers classification creep: a document that consolidates sources from several levels ends up classified at the highest of them, and without a managed downgrade the labels only ever ratchet upward.