CS 513 - System Security
Lecture 16

Lecturer: Professor Fred B. Schneider
Notes by: Vicky Weissman
Lecture Date: 3/28/00


Today's Topic - Authorization

High Level Picture

To build a secure system:
1. model the system so that it can be analyzed
2. formulate a policy (set of acceptable behaviors) with respect to the model
3. employ mechanisms to implement the policy

Example:
Real System: our lecture room
Model: a closed space with a door.
Policy: only allow Cornell students into the lecture room.
Mechanism: a guard at the door who only allows someone into the room if they have a Cornell ID.

Problems:

Any discrepancy between our model and the real world may constitute a vulnerability
(ex. lecture room has open window, model doesn't.)

Enforcing a policy does not necessarily mean that a system is secure
(ex. lecture room is not 'secure', because only Cornell students can enter.)

Policy and mechanism choices are not independent. Certain policies cannot be enforced with particular mechanisms.
(ex. to restrict access to Cornell students, need a mechanism to identify Cornellians.)

General Model for Access Control

Model:
1. Subject makes a request to the policy-enforcing mechanism.
2. The mechanism consults the policy and either grants or denies the request.

Problems:
Model assumes complete mediation (there is no way to bypass the policy-enforcing mechanism.)
Model assumes that every request can be evaluated based on stored information of past actions.

Example:
Consider a system that tries to keep salaries private by enforcing the policy that salaries cannot be printed to the screen. The policy-enforcing mechanism must deny requests that try to print a person's salary. At the same time, the mechanism must accept requests to print a number that happens to be a salary, if that number does not actually refer to a salary (otherwise trying to print every number would reveal the secret, since unprinted numbers would be salaries.) A mechanism that follows the general model for access control cannot make the necessary distinction to maintain privacy.

Access Control Matrices (ACM)

Useful Definitions:
An object is a passive entity in the system.
A subject is an active entity in the system.
Since subjects can manipulate each other, every subject is an object.

Purpose of ACM:
To represent access rights in the system

ACM Structure:
2-dimensional matrix in which element (i, j) contains subject i's access rights to object j.
An element (i, i) may contain i's general rights, such as a sysAdmin right.
For completeness every subject must correspond to a row of the matrix and every object must correspond to a column.
Neither the rows nor the columns need to be in any particular order.

Modifying ACM through Commands:
As the system's state changes, commands are used to update the ACM. Examples of basic commands include createSubject (adds a row and a column to the ACM), createObject (adds a column), deleteSubject (removes a row and possibly a column, based on the command's specification), and deleteObject(remove a row and possibly a column). Commands may be more specific such as createFile.

In general, a command is passed the names of relevant subjects and objects, it then checks that the change is allowed, and, if it is, modifies the ACM. For example, read access may be given by invoking the following command:


confer.read(p, q, f) {if (own ( (p, f)) then grant read(q, f)}

where own and read are rights in the ACM,. p and q are subjects, and f is an object.
This command assumes that the caller was a subject that is allowed to change rights on objects owned by p. A mechanism is needed to ensure that this assumption is correct.

Applying the Principle of Least Privilege to ACMs:
What rights should a procedure have when it is running? If the procedure has all the rights of the caller, then the principal of least privilege is clearly violated. Similarly, a procedure that is being run by multiple callers at the same time, should not have every right of every caller simultaneously. The procedure needs a different set of access rights per caller and those rights should be restricted to exactly the ones needed for the procedure to do its job. To accomplish this, each procedure call is overloaded by a protected procedure call. The protected procedure is a subject in the ACM. It has the common access rights that are needed every time the procedure is called (regardless of who the caller is).

If a subject has the 'enter' right for the protected procedure, then the subject can make a protected procedure call. When this happens, a new subject is added to the ACM with the rights of the protected procedure and the rights given to it by the caller. The procedure is then executed in the new subject's domain (the domain is the set of objects that can be accessed or the set of instructions that can be executed next). When execution finishes, the new subject is deleted.

Example: Snapshot of ACM after both User 1 and User 2 have called the text editor.

Things to Note:
1. Every subject is an object.
2. Editors 1 and 2 have both the rights in the Editor domain and the rights given by the caller.
3. To call the editor, each subject needs the editor's 'enter' right.
4. The editor rows cannot be replaced by giving the caller read access to the dictionary, without allowing the caller to use the new right for activities unrelated to the editor (doesn't follow principal of least privilege).
5. Each time editor is called, a new subject must be created. If the last 2 rows of the ACM were combined, then each user could r/w the other user's files.