Access Control Policies and Mechanisms

Lecturer: Professor Fred B. Schneider

Lecture notes by Lynette I. Millett
Revised by Borislav Deianov
Today we talk about what security is. Security is, in many ways, like correctness. What do we mean that a computer program is correct? Correctness is relative to a set of specifications or documentation. In the same way, security will be relative to a set of policies. (Example of a policy: no student is allowed read the grades of another student).

We start by defining policy. A policy is a set of acceptable behaviors. Note that we have not formally defined "behavior" but it can be modelled as the sequence of instructions the computer executes or the sequence of images that appear on the screen, etc.

Policies are defined with respect to abstract models. Consider the following example: A student walks to the entrance of a room and shows his/her ID to the guard. The guard looks up the student's name in a list of students and lets the student in the room if the name is on the list. This model ignores all sorts of details. What if the student's ID is dirty and illegible? What if the student borrows somebody else's ID or enters through the window instead of the door? Models are abstractions, and in choosing to deal with abstractions we ignore some aspects of reality. It is important to keep in mind that anything ignored by the model may constitute a vulnerability

In this course we discuss policies and mechanisms for enforcing those policies. Ideally, policies and mechanisms would be completely disjoint. We like to believe that any policy can be enforced by the set of mechanisms that our computer systems provides. In practice, this is not true. In choosing a security mechanism, we restrict our choice of security policies. Example: with only a list of student names at the door we cannot restrict admission to the figure skaters, since we have no way of determining who is a figure skater.

We now describe a particular model of access control. Our model will be concerned with subjects and objects. The subjects are the active entities (a.k.a. principals) that do things, the objects are the passive entities to which things are done. Examples of subjects might be a person or a process on a computer, an example of an object might be a file or a subroutine. The sets of subjects and objects need not be disjoint (and there is good reason for them not to be, as we see below).

Our model of access control is illustrated as follows:

Here we are presuming Complete Mediation: Every request any subject makes will be checked and the decision is based on past actions (and perhaps some stored information that summarizes those past actions). In our example of the guard at the door, this assumption is equivalent to postulating that students are not allowed to come through the window---only through the door---where their ID is checked against a list (=stored information)

It turns out that with this model we have actually ruled out some interesting policies. Consider the following example: We might want a computer system that restricts the ability to learn the professor's salary (say that it is $20,000). If a subject attempts the operation "read the salary file" the mediation mechanism can deny that request. But suppose some program attempts to print "$20,000". Should this action be allowed? If we disallow the action because this happens to be the professor's salary, then we have problems. First, there might be many salaries in the salary file, and we will have to restrict any program from printing those different numbers. Second, a user might note that requests to print certain numbers are blocked and thereby infer something about professorial salaries. On the other hand, there are many ways a program might learn about a salary (for example, by looking in some buffer in memory or observing the timing and frequency of disk accesses, etc.), so if printing $20,000 is allowed then the program could reveal the salary. A mechanism to enforce this sort of information flow must be able to identify the source of information it is printing, and this is not something that a mechanism as outlined above can do (because analyzing the program text is required). Conclusion: Some useful policies are sacrificed by choosing the model we have.

Access Control Matrix

We can represent access rights enforced by complete mediation using an access control matrix. Let Neither set is ordered, and we postulate that Subj is a subset of Obj. Subjects are active entities, and we want subjects to be able to do things to other subjects (e.g., processes can send kill signals to other processes), so it is sensible that Subj be a subset of Obj.

The system state with respect to access control can be represented in a matrix, as follows:

Each entry of the matrix stores the access rights that the subject of that row has to the object of that column. We denote this: [S, O].

Systems are not static, and there will often be changes in access rights of subjects to objects. We therefore specify commands that will change state as follows:

where the arguments to the command are names of elements in Obj. Note that the conditions of the if statement are predicates, either true or false. Operations (Op1, Op2, etc.) change the protection matrix. They include: as well as operations that grant and take back rights such as: We have described a simple programming language. For the purposes of our discussion, we disregard details such as how to handle deleting an object that does not exist.

Using this language, we can postulate protection commands that model, for example, creating a file, conferring read rights and revoking read rights, as follows:

In the proposed scheme, any right a subject S has to an object can be conferred to any other subject S' if S has "own" rights over the object.

Subjects can be processes or users. Recall the principle of least privilege from the last lecture. We wish to only give enough access to subjects so that they can do their intended jobs, and no more. Suppose that a row in the access matrix corresponds to a process. This would be inconsistent with the least privilege principle. A process has a definite lifetime and may not need all of its access rights throughout that entire lifetime. We therefore would like to find a way to maintain small protection domains for subjects.

A process that changes from one small protection domains to another as execution proceeds can obey the Principle of Least Privilege. We implement multiple small protection domains by associating multiple rows of the access control matrix with a process. Each row defines a domain. However, now we need to allow a domain (subject) to transfer control to another. An "enter" right for one domain to the other permits such a cross-domain transfer.

The issue now is to identify criteria for a domain change, and make sure causing these domain changes does not end up adding work to the programmer. We solve this problem by overloading procedure call with domain changes to get protected procedures. Each protected procedure executes in its own protection domain. Thus, execution in a protected procedure has certain inalienable rights. Some of these rights come from arguments in the call, others from information obtained statically.

We give an example of a protected domain. Imagine that subjects consist of a user and an editor, and that the objects are some files and a spelling-checker dictionary. The matrix may look as follows (without the dotted arrows):

Upon invoking the editor, the access matrix changes, and the r/w privileges move from the first column to the second (as indicated by the dotted arrows). Also, note that only the editor has access to the dictionary.

Now, suppose there are two users that wish to invoke the editor:

In this case, it appears that the editor has access to all three files. In practice, there will be two copies of the editor running and we desire that each copy only has access to the files of one user. The solution is to invent a "template" domain. A procedure call (such as invoking the editor) causes a new domain to be constructed based on the template. This adds a new subject/row to the matrix. Upon return from the procedure call the instantiated domain is destroyed and the process continues execution in the user domain.