Access Control

Access control is a process that make sures that users can do what they are permitted to do (and no more than that).
Permission to access a resource is called authorization.

Obviously, access control is a foundational topic of computer security. If a non-authorized user (i.e., an attacker) gains access to resources of your system, your system has been compromised; your system is not secure.

Examples

Access control works at a number of levels:

(Application level) At the application level, the access control mechanisms may express a very rich and complex security policy. For example,
- A modern online business could assign staff to one of dozens of different roles, each of which could initiate some subset of several hundred possible transactions in the system.
- On a modern social networking site, the access control mechanisms will have a thicket of rules and options about who can see, copy, and search what data from whom.
(Middleware) The applications may be written on top of middleware. Examples include:
- A database software typically has access controls specifying which dictionaries a given user can select, and which procedures they can run.
- A bookkeeping software may ensure that a transaction which debits one ledger for a certain amount must credit another ledger for the same amount.
(Operating system)
- The operating system provides access control for files.
- With the assistance of hardware features (CPU or memory management hardware), the operating system also controls which memory addresses a given process can access.

Subjects and Objects

When we discuss access control, we use the terms like subjects and objects.

A subject is an active entity that accesses objects. For example, a user in your system is considered a subject. A running program (i.e., process) like a web server is also a subject.
An object is the resource that a subject would like to use. The resource is often a file but may also be a device, communication link. Depending on a situation, another subject can also be an object.

Reference monitor

A reference monitor enforces an access control policy over subjects (e.g., processes and users) ability to perform operations (e.g., read and write) on objects (e.g., files and sockets) on a system.

There are a few requirements that the reference monitor of a system should satisfy.

(complete mediation) The reference monitor must always be invoked.
(verifiable) The reference monitor must be small enough to be subject to analysis and tests, the completeness of which can be assured.
(tamper-proof) The reference must be tamper-proof.

Access Control Matrix

A straightforward method that we can use to specify which subjects can access which objects is using a big matrix. In particular, in an access control matrix:

Each row of the table is associated with a subject.
Each column of the table is associated with an object.
Each cell (that is, the entry for a particular subject-object pair) indicates the access mode that the subject is permitted to exercise on the object.

	/etc/passwd	/usr/bin/python3	/home/alice	/home/bob	...
root	read, write	read, write, execute	read, write, execute	read, write, execute
alice	read	read, execute	read, write, execute
bob	read	read, execute		read,write, execute
...

The above shows a toy access control matrix for a fictional file system.

We see three subjects: root, alice, bob
We see four objects: /etc/passwd, /usr/bin/python3, /home/alice, /home/bob
While alice has full access (i.e., read, write, and execute) to /home/alice, bob has no access to that object.

Drawbacks

With an access control matrix, determining which subject can access which object is super easy and quick, which is good! However, there are a few drawbacks that discourages people from using the access control matrix.

Usually, there are a very large number of subjects and objects, which makes the size of the matrix too big. For example, nowadays any reasonable server will often have 1,000 subjects (i.e., processes), and 1,000,000 objects. This implies that just storing this matrix needs 1 billion cells, and this is too much overhead to take as an efficient access control mechanism.

Do you think the administrator will be happy with filling up these billion entries?
If you think about it more, most entries will probably be blank or default. Storing these pieces of information using the matrix seems like a big waste of space. There should probably be a better way to save the space.
Whenever the system adds (or deletes) an object or a subject, the matrix has to be updated accordingly, but that means adding or deleting an entire row or column! This will take way longer than you would want. Suppose you open an editor and create a file, and it takes a minute. Do you want to use that kind of system?

Access Control Lists

Access control lists are one way to overcome inefficiency of the access control matrix mechanism.

Each object is associated with a linked list. That is, if there are 1000 objects, then there are 1000 lists.
In a sense, access control lists can be viewed as storing the columns of the access control matrix with the appropriate object.
In each list, there are subjects with access rights to the associated object.
The space of a list can be saved by not storing subjects with no access.

Pros and cons

ACLs provide the following advantages:

The main advantage of ACLs is size. All empty cells in the access control matrix doesn't claim any storage in ACLs,
ACLs work naturally well with a file system. An ACL for each file object can be stored directly in the header block for that file. Given an access request to a file, an OS can make a decision by checking its ACL residing in the header block.

However, there are some disadvantages as well:

ACLs are not good for enumerating all access rights for a given subject. This task has to involve checking the ACL of every object.
For example, if a subject is to removed from a system, the system has to deal with this problem.

Access control lists (ACL) in UNIX

The UNIX file system implements the concept of access control lists. As shown in the above, each file allows permissions set for

the owner of the file,
the group to which the owner belongs, and
everyone else (all).

$ ls -alF
...
-rw-r--r--  1 choi scs   126 Oct 21 21:44 sh.txt
-rw-r--r--  1 choi scs   127 Nov  4 10:37 shtxtcode.txt
-rwxr-xr-x  1 choi scs 16952 Oct 31 22:08 stack*
-rw-r--r--  1 choi scs   337 Oct 31 22:08 stack.c
...

For example, consider file stack in the above:

 -rwxr-xr-x  1 choi scs 16952 Oct 31 22:08 stack*

rwx: the owner has read/write/execute rights.
r-x: any member of the group scs has read/execute rights.
r-x: every one else has read/execute rights.

One can use shell commands like chmod, chown, chgrp to change the permission.

If one needs an access control list that is more granular than owner-group-others permissions, UNIX provides the following commands:

getfacl: get file ACL.
setfacl: set file ACL.

We are going to learn more about these commands during the lab.

~$ getfacl README
# file: README
# owner: choi
# group: scs
user::rw-
user:www-data:rwx               #effective:rw-
user:choi:rwx                   #effective:rw-
group::r-x                      #effective:r--
mask::rw-
other::---

Access control lists in Windows

Windows also provides ACL. To view or change a Windows ACL, right click "Properties", click the "Security" tab, and click "Advanced".

Capabilities

In another approach, capabilities take a subject-based approach. That is, for each subject, there is a list containing all the objects and the access rights for that subject. For example, the capability of alice is showne below.

alice: (/etc/passwd, r), (/usr/bin/python3, rx), (/home/alice, rwx)

ACLs vs Capabilities

In principle, ACLs are good at finding all subjects who have access to a given object, and capabilities are good at finding all objects that a given subject can access.
With capabilities, subjects are explicitly aware of the permissions that they hold, which is good in general. However, with capabilities it is difficult to make a file readable to everyone, which is easy with ACLS by having the "default access rights" to be readable.
When a subject wants to delegate its capabilities to another subject, this job can be done easily with capabilities. In a sense, delegation is a simple transfer of one's capabilities to another. With ACLs, delegation gets more difficult.

ACLs and Capabilities with iPhone/Android

Each file has an ACL.
Apps have capabilities. They can request a capability to access device services such as the mobile network, the phone, SMSes, the camera etc. The capability is granted if the user consents.

Discretionary Access Control (DAC) vs Mandatory Access Control (MAC)

DAC vs. MAC

In Discretionary Access Control (DAC), the controls are discretionary in the sense that subjects control the access permissions of the objects. For example, with the UNIX file system, owners freely set access permissions to their objects.
Mandatory Access Control (MAC) is a form of access control where policy is centrally enforced and users cannot override the policy. With MAC, access control is mandated by system policy. The policy and the rules for access and dissemination cannot be changed by the subject. In particular, even if you are the owner of an object, you must abide to the policy too.

When DAC is not sufficient

The DAC model often works poorly in environments where management needs to enforce its policies and define access permissions. For example, consider the following situation:

To summarize:

Alice is eligible to read the restricted document.
After reading the document, Alice (well, actually the Trojan horse) created a copy of it that everyone can access.

So, how could we fix the problem? The problem is, with DAC, it's hard to fix this once Alice's account is compromised. After reading the file, she can always create and write her own file, by the definition of DAC.

Example of MAC: The Bell-LaPadula (BLP) Model

The Bell-LaPadula model puts subjects and objects in security levels. One example is the U.S. military classification scheme:

top secret > secret > confidential > restricted > unclassified

A subject is said to have a security clearance of a given level.
An object is said to have a security label of a given level.

Properties

The BLP model defines the following two properties:

Simple Security Property (SSP). A subject can read an object only if the security clearance of the subject dominates or equals the security label of the object. This is also known as no-read-up rule.
The *-property (star property). A subject can only write into an object of greater or equal security level. This is also known as no-write-down rule. Because of this rule, one cannot spill classified information.

If you think about it, these two properties make sure of the following:

A subject that can read data in some security label cannot write to an object with lower security label.

Basic Security Theorem

Actually, Bell and LaPadula proved a Basic Security Theorem in their paper:

If a system starts in a secure state (i.e., confidentiality is guaranteed), and if each access doesn't violate the above properties, then the system remains in a secure state.

The fact that their access control system can be rigorously proved to be secure is quite cool!

Limitations of BLP model

Although it is provable secure, the BLP model mainly works only for confidentiality; it only prevents unauthorized disclosure. BLP doesn't deal with the integrity of the data.

MAC in Android, iOS and Windows

Android: Since its 5.0 release it has used SELinux (Secure Linux) to enforce a MAC security model on top of its original UID-based DAC approach.
For instance, software must typically run as the root user account to write to raw block devices.
- In a traditional DAC-based environment, if the root user becomes compromised that user can write to every raw block device.
- However, SELinux can be used to label these devices; even the process with the root privilege can write to only those specified in the associated system policy. In this way, no process can overwrite data and system settings outside of the specific raw block device against the system policy.
Likewise, Apple also has a MAC framework (TrustedBSD).
Microsoft: Starting with Windows Vista and Server 2008, Windows incorporates Mandatory Integrity Control (MIC). MIC uses integrity levels and mandatory policy to evaluate access.
Security subjects and securable objects are assigned integrity levels that determine their levels of protection or access. For example, a subject with a low integrity level cannot write to an object with a medium integrity level, even if that object's DACL allows write access to the subject.