Access control fundamentals

Access control decides what each principal may do, and is not authentication

A shared system has more than one principal on it, and not everyone should be able to do everything. A bank’s customer should not be able to open the vault; a program should not be able to read another user’s passwords. Access control is the part of a security policy that decides, for every principal and every resource, exactly what that principal may do with it. A principal is a user, a group, a process or a machine.

Compare

Authentication

The process of acquiring evidence of the identity of another party. It answers “who are you?”

Authorisation

The allocation of a privilege to a party. It answers “what are you allowed to do?”, and only makes sense once authentication has answered the first question.

Access control is neither of those. It is the ongoing decision of which principal may do what to which resource, and it covers both steps.

Pitfall

Do not write “access control” when you mean “authentication”, or the reverse. A system can authenticate a user correctly and still make the wrong authorisation decision, and a badly authenticated identity can still be correctly authorised once it is, wrongly, accepted. They are two separate failures with two separate causes.

Policy, mechanism and assurance describe any access control scheme

Access control sits inside the same reference framework as the rest of this unit. It is specified as policy (what is and is not allowed), enforced by one or more mechanisms, and backed by assurance (how much confidence there is that the mechanism actually works). A password is a mechanism; how strong that password is sets how much assurance it provides. The policy counters the incentives of an attacker who wants a resource or asset they are not entitled to.

The access control matrix is what every scheme stores

The decision is modelled as a matrix: subjects (principals) down the rows, objects (resources) across the columns, and each cell holding the rights that subject has over that object, r for read, w for write, x for execute, - for nothing. Every scheme covered later in this module (discretionary and mandatory control, access control lists, capabilities) is a different way of storing or enforcing exactly this matrix.

Sam is the administrator: full access everywhere except the audit trail, which even he can only read. Alice, the manager, can run the OS and the program through their approved interfaces but not write to either — she can tamper with data, not with the tools — and she cannot see the audit trail at all. Bob, the auditor, can read everything and change nothing. (source: Week 3 notes, Table 1)

Exam detail

The unit’s own worked example is Table 1 in the Week 3 notes: Sam, Alice and Bob against six objects. Sam is the administrator, with full access everywhere except the audit trail, which even he can only read. Alice, the manager, can execute the operating system and the program through their approved interfaces, but cannot write to either, and she has no access to the audit trail at all. Bob, the auditor, can read every object and write to none. Read a cell as “what this row’s subject may do to this column’s object”, and the whole table follows from each person’s role.

Recall

A cell in the access control matrix is empty for subject S and object O. What does that mean?

S has no rights over O at all: not read, not write, not execute. An empty cell is not a missing entry to be filled in later; it is itself a decision.

Rights should match the role, so the matrix is built cell by cell

A principal granted more rights than its role needs can misuse them, by deliberate attack or honest mistake. The larger the gap between what a principal can do and what it needs to do, the more damage that gap allows. The lecture’s matrix closes that gap person by person: Alice’s rights stop at reading and writing the data she manages and never extend to the operating system or program she merely runs.

Optional aside

The matrix in Table 1 is deliberately called “naive” in the lecture’s own slides. Storing it as a literal grid does not scale: most cells are empty, and a real system needs a cheaper way to store the same information. That is exactly the problem the next topic solves.