Access control is a security technique that can be used to regulate who or what can view or use resources in a computing environment. It’a a binary decision where we can allow or deny access to a resource.
An access rule is a tuple where is the subject, is the object, and is the action. The action can be read, write, execute, delete, etc.
Access control is composed by a set of rules that define who can access a resource and what actions can be performed on it. It’s not possible to list all the possible access rules, so we need to condense and make them more general.
The reference monitor is a crucial component responsible for enforcing access control policies, determining “who can perform what action on which resource.” It is an integral part of all modern operating system kernels, exemplified by the Security Enhanced Linux (SELinux) in Linux systems. To qualify as a reference monitor, the entity must meet the following criteria:
Tamper-proof: The reference monitor must be impervious to modifications.
Non-bypassable: It must not be possible to circumvent the reference monitor, even by a system administrator.
Verifiable: The reference monitor must be sufficiently small and straightforward to allow comprehensive verification and testing by human inspectors.
flowchart LR
Principal[Principal] --> AccessRequest(Access Request) --> ReferenceMonitor[Reference Monitor] <--> Object[Object]
subgraph Authentication
AccessRequest
end
subgraph Authorization
ReferenceMonitor
Object
end
It’s important to distinguish between authentication and authorization:
Definitions
Authentication: it’s the process of verifying the identity of a user.
Authorization: it’s the process of deciding if a user has the necessary permissions to access a resource.
The reference monitor verifies the identity of the principal (user) making the request. The user, to be authenticated, must enter a username and a password (or other credentials) in the system. If the values entered are correct, the user is authenticated and the system runs on behalf of the user. This might be intuitive, but it’s imprecise: log-on creates a process that runs with access rights assigned to the user and typically the process runs under the user identity of the user who has logged on. For the authorization, the reference monitor decides whether access is granted or denied. It has to find and evaluate the security policy relevant for the given request.
Requests to reference monitor do not come directly from a user or a user identity, but from a process. The active entity making a request within the system is called the subject.
We must distinguish between these concepts:
Concept
Description
User
Person
Principal (User identity)
Name used in the system, possibly associated with a user; Active entity
Subject
Process running under a given user identity
Object
Passive entity - file or resource
Access operations
Vary from basic memory access (read, write) to method calls in object-oriented systems
Access Control Models
Access control models are primarily categorized into three types: Discretionary Access Control (DAC), Mandatory Access Control (MAC), and Role-Based Access Control (RBAC). These models offer distinct frameworks for managing permissions and access rights within a system.
Discretionary Access Control (DAC) allows the owner of the resource to determine who can access it. The central principle here is the discretionary aspect, whereby the resource owner exercises discretion in granting permissions to others.
Mandatory Access Control (MAC) operates on a more stringent and predefined set of policies established by a central authority. In this model, access rights are assigned based on regulations and classification levels.
The central distinction between DAC and MAC lies in the entity responsible for assigning privileges: DAC places this responsibility in the hands of the resource owner, whereas MAC entrusts it to a centralized policy administrator.
Role-Based Access Control (RBAC) introduces a different approach by abstracting permissions from individual identities and associating them with roles. Users are assigned to roles, and roles are assigned access rights, which streamlines the management of permissions. This abstraction facilitates more efficient and scalable management of user privileges, particularly in complex and large-scale environments.
In summary, DAC, MAC, and RBAC represent fundamental paradigms in access control, each with its unique mechanisms and use cases, shaping how permissions are allocated and enforced in various systems.
Discretionary Access Control (DAC)
In DAC, the resource owner discretionarily decides its access privileges. This is the most common access control model and all off-the-shelf OSs implement it.
Examples of DAC systems:
Unix: subjects are users and groups, objects are files, and actions are read, write, and execute. In Linux, the permissions are represented by a triad of read, write, and execute permissions for the user, group, and others. You can see the permissions of a file by running ls -l command in the terminal.
For example, if you have a file file.txt with the following permissions:
$ ls -l-rw-r--r-- 1 user group 0 Jan 1 00:00 file.txt
-rw-r--r--: permissions of the file (file type (1 char)), user permissions (3 chars), group permissions (3 chars), others permissions (3 chars)) where r is read, w is write, and x is execute
user: owner of the file
group: group of the file
0: size of the file
Jan 1 00:00: last modification date
file.txt: name of the file
Windows: subjects are roles instead of groups, multiple ownership of users and roles over files, objects are files and “other” resources, and actions are delete, change permissions, and change ownership. In Windows, the permissions are represented by a list of users and groups with their permissions. You can see the permissions of a file by right-clicking on it, selecting “Properties”, and then “Security”.
In DAC we need to model the following entities:
Subjects who can exercise privileges (rights)
Objects on which privileges are exercised
Actions which can be exercised
The protection state is a triple where is a matrix with rows and columns and is the privileges of subject over object .
Transitions in the HRU model
In general, at runtime a file has a protection state, defined by the triple where and stand for Subjects and Objects respectively, while is a matrix with rows and columns. Each cell of the matrix defines the privileges of subject over object, where the privileges are read, write and own (ownership can be added). This matrix is called Access Control (AC) matrix and belongs to HRU model (named after its creators).
In HRU model there are also some basic operations:
create (destroy) subject so add (remove) a row to AC matrix
create (destroy) object so add (remove) a column to AC matrix
add (remove) so change the cell’s content
A sequence of basic operations is called transition: transition allow to create/destroy files, change permissions and so on.
Example
For example a transition used to create file (subject ; file ) would be: create object and add “own” into and add “read” into . This transition is not always correct: if the file already exists and is owned by another user, when executing this transition the existing file is being stolen from its owner.
Before creating a file it’s necessary to check whether the file exists already or not. Every time a transition is defined in HRU, the correctness of the transition must be verified, to avoid files being stolen: this is the so-called safety problem. It is necessary to verify that from an initial protection state there is no possibility of writing a transition that steals someone else’s file. The system must be secure by design.
In general, when working with transition, it is necessary to decide whether, given an initial configuration and a sequence of transitions, can obtain a right on . The answer to this question depends on what the owner allows on that specific file: if the owner allows it the answer is yes, but if, despite the owner denying it, it is possible to obtain such right, the set of commands (transitions) is unsafe by design.
Note
In a formal way: given an initial protection state and a set of transitions, is there any sequence of transitions that leaks a certain right (for which the owner is removed) into the access matrix? If this does not happen the system is safe with respect to right .
In a generic HRU model this is not decidable, it is only decidable in simple system (mono-operational) or when subjects/objects are finite. The safety problem is in general a problem of DAC systems. The correctness inside AC matrix must be checked, to avoid leaking privileges (which would mean leaking files from other users).
Common DAC implementations
There are several ways to implement DAC:
Reproduction of HRU models: this is the most common implementation and it’s used in most operating systems (e.g., Linux, Windows, Mac OS X)
Access matrix is a sparse matrix in which most of the elements are zero. This implementation is efficient when the number of subjects and objects is high
Alternative implementations are:
Authorizations table: records non-null triples , typically used in DBMS
Access Control Lists: records by column (i.e., for each object, the list of subjects and authorizations). It focuses on the object and ACLs are equivalent to columns of the access control matrix
Capability Lists: records by row (i.e., for each subject, the list of objects and authorizations). It focuses on the subject and capabilities are equivalent to rows of the access control matrix
ACLs
Capabilities
Efficient with per object operations
Efficient with per subject operations
Most common case
Usually objects change and subjects stay, so inefficient
Some systems (e.g., POSIX) use abbreviated ACLs
Capabilities are optional in POSIX (Linux and BSD)
Cannot have multiple owners (partially achievable via groups)
General DAC shortcomings
DAC systems have some shortcomings: it is not possible to prove their safety (undecidable), moreover, only access to objects is controlled, while access to the data inside the object is not, since privileges can not be granted to what is inside an objects. There is thus a granularity problem: it is not possible to check what the object contains and this makes the system susceptible to issues related to malicious user or trojan horse.
Definition
Trojan horse problem consists of a malicious program running with owner privileges: therefore a malicious user can trojanize the program (used by other users too) and, since the program (run by other users as well) is making operations on some files, the trojan horse that was put inside the program can operate on it, although its owner can not.
In this case, DAC can provide privileges on the entire program (e.g. word processor), but not on what is inside it. If a functionality exists, within the program, that allows to read and copy data, the trojan horse will not be blocked. Trojan horse is at a lower granularity level, than the one controlled by DAC.
Another issue of DAC is related to scalability and management: each user-owner can potentially compromise security of the system with their own decision.
Mandatory Access Control (MAC)
IDEA
MAC do not let owners assign privileges. Privileges are set by a security administrator who defines a classification of subjects (or “clearance”) and objects (or “sensitivity”). The classification is composed of a strictly ordered set of secrecy levels and a set of labels.
Classification is a partial order relationship where dominance in a lattice is defined as:
Rule 1 (no read up, “simple security property”): a subject at a given secrecy level cannot read an object at a higher secrecy level
Rule 2 (no write down, “star property”): a subject at a given secrecy level cannot write an object at a lower secrecy level
It also defines one DAC rule:
Rule 3 (Discretionary Security Property): states the use of an access matrix to specify the discretionary access control
The Bell-LaPadula model also defines the tranquility property: secrecy levels of objects cannot change dynamically. This results in a monotonic flow of information toward higher secrecy levels, so we need trusted subjects who can declassify or sanitize documents.
The Bell-LaPadula model has limitations as it does not address integrity. There are other models for integrity, e.g., the Biba model.
