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:
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.
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:
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.