A (very) brief history of Access Control

Basic Concepts

An access control mechanism controls the accesses performed by an active entity (subject) over a passive entity (object) according to a given access mode.

• Subject: user, process, etc.
• Object: file, resource, etc.
• Access mode: read, write, execute, etc.

Access Matrix

The seminal work is considered to be the Access Matrix (Lampson, 74), where each row is associated with a subject, and each columb with an object. For instance, an access matrix with N subjects and M objects could like the following:

In this matrix, S₂ cannot access O₁ at all, can write and execute O₂, and can read O_M. Each object is associated with an owner, and the owner of that object can set the right at their discretion, which is why this model is known as Discretionary Access Control. Although this model is flexible, it would enable an owner with confidential information to grant access to all users, even by mistake.

Bell-LaPadula

To address this problem, which can be particularly crucial in a military setting, Bell and La Padula introduced a new model (Bell & Lapadula, 76), usually named after them and abbreviated BLP. The main idea behind the BLP model is that each subject is associated with a clearance level taken from the lattice, and each object is associated with a confidentiality level also taken from the lattice.

The BLP model then specifies three rules:

• A subject with clearance c can read an object with confidentiality l if, and only if c is higher or equal to l
• A subject with clearance c can write into an object with confidentiality l if if, and only if l is higher or equal to c
• Any access must respect a provided access matrix

The second rule can be a bit counter-intuitive, since it effectively means that someone with a very low level of security can write into the most sensitive documents! However, in practice, the access matrix (third rule) is unlikely to grant much access to someone with a very low level (and certainly not to the most sensitive documents). In addition, being able to write into a document does not mean one can edit that document: both read and write access are required to effectively edit a document. The BLP model is known a Mandatory Access Control, since it is impossible to circumvent the policy: if someone with a high clearance gives the permission to a user with a low clearance to a file with a high level of confidentiality, that user can only access the file if the lattice allows it. The combination of the first and second rule makes it impossible for information to “flow down”, i.e., information in high-level documents cannot be copied into low-level documents.

Example of a BLP lattice

For instance, a subject with clearance Secret, {Air} can read any file labelled as Secret, {} and Secret, {Air}, and can write into any file labelled as Secret, {Air}, Secret, {Air, Sea}, Top Secret, {Air} and Top Secret, {Air, Sea}.

Chinese Wall

The BLP model provides a very hierarchical model, which not always suitable. In particular, in the context of commercial applications, the main problem to manage is not hierarchy, but conflict of interest. For instance, a lawyer can work for a bank and an oil company, but not for two different banks, due to possible conflicts of interest. Brewer and Nash introduced the Chinese Wall model (Brewer-Nash, 89), which states that, at first, a subject can access any object. However, as soon as they have accessed an object from a company, then they can no longer access objects from a different company belonging to the same conflict of interest class.

Example of a Chinese Wall model with two conflict of interest classes.

For instance, in the example above, if a lawyer accesses the object O₂, then they can access O₁, O₄ and O₅, but not O₃.

RBAC

A very popular access control model is Role-Based Access Control (RBAC), introduced by Ferraiolo et al (1995) and Sandhu et al (1996). RBAC is considered to be a more flexible model compared to BLP and the Chinese Wall. Each subject is associated with a set of roles, and each role is associated with a set of permissions, where a permission describes an access mode over an object. At run-time, each subject decides to activate one or several of their roles, and they can access an object according to an access mode only if at least one of the roles is associated with the corresponding permission. Many RBAC extensions exist, for instance introducing a role hierarchy (permissions from a junior role are automatically inherited by a senior role), separation of duties (a subject cannot activate two specific roles at the same time), or administrative roles (a role that has the permission to associate permissions to a role or roles to a subject).

Consider for instance the case with two users, Alice and Bob, such that:

• Alice has the role ROLE_admin
• Bob has the role ROLE_user
• The role ROLE_admin has the permission FILE_write and FILE_read
• The role ROLE_user has the permission FILE_read.

The evaluation of a query which includes Bob who has activated the role ROLE_user and trying to use the permission FILE_write is denied according to RBAC, as illustrated below. Note that if Bob tries to activate ROLE_admin, the request is still denied, since Bob is not associated with that role. However, if Bob tries to use the permission FILE_read instead, then RBAC permits it.