2.2. Access Control Matrix Model
The simplest framework for describing a protection system is the access control matrix model, which describes the rights of users over files in a matrix. Butler Lampson first proposed this model in 1971 [543]; Graham and Denning [252, 370] refined it, and we will use their version.
The set of all protected entities (that is, entities that are relevant to the protection state of the system) is called the set of objects O. The set of subjects S is the set of active objects, such as processes and users. In the access control matrix model, the relationship between these entities is captured by a matrix A with rights drawn from a set of rights R in each entry a[s, o], where s e S, o e O, and a[s, o]  R. The subject s has the set of rights a[s, o] over the object o. The set of protection states of the system is represented by the triple (S, O, A). For example, Figure 2-1 shows the protection state of a system. Here, process 1 can read or write file 1 and can read file 2; process 2 can append to file 1 and read file 2. Process 1 can communicate with process 2 by writing to it, and process 2 can read from process 1. Each process owns itself and the file with the same number. Note that the processes themselves are treated as both subjects (rows) and objects (columns). This enables a process to be the target of operations as well as the operator.
Interpretation of the meaning of these rights varies from system to system. Reading from, writing to, and appending to files is usually clear enough, but what does "reading from" a process mean? Depending on the instantiation of the model, it could mean that the reader accepts messages from the process being read, or it could mean that the reader simply looks at the state of the process being read (as a debugger does, for example). The meaning of the right may vary depending on the object involved. The point is that the access control matrix model is an abstract model of the protection state, and when one talks about the meaning of some particular access control matrix, one must always talk with respect to a particular implementation or system.
The own right is a distinguished right. In most systems, the creator of an object has special privileges: the ability to add and delete rights for other users (and for the owner). In the system shown in Figure 2-1, for example, process 1 could alter the contents of A[x, file 1], where x is any subject.
|
EXAMPLE:
The UNIX system defines the rights "read," "write," and "execute." When a process accesses a file, these terms mean what one would expect. When a process accesses a directory, "read" means to be able to list the contents of the directory; "write" means to be able to create, rename, or delete files or subdirectories in that directory; and "execute" means to be able to access files or subdirectories in that directory. When a process accesses another process, "read" means to be able to receive signals, "write" means to be able to send signals, and "execute" means to be able to execute the process as a subprocess.
Moreover, the superuser can access any (local) file regardless of the permissions the owner has granted. In effect, the superuser "owns" all objects on the system. Even in this case however, the interpretation of the rights is constrained. For example, the superuser cannot alter a directory using the system calls and commands that alter files. The superuser must use specific system calls and commands to create, rename, and delete files. |
Although the "objects" involved in the access control matrix are normally thought of as files, devices, and processes, they could just as easily be messages sent between processes, or indeed systems themselves. Figure 2-2 shows an example access control matrix for three systems on a local area network (LAN). The rights correspond to various network protocols: own (the ability to add servers), ftp (the ability to access the system using the File Transfer Protocol, or FTP [728]), nfs (the ability to access file systems using the Network File System, or NFS, protocol [149, 886]), and mail (the ability to send and receive mail using the Simple Mail Transfer Protocol, or SMTP [727]). The subject telegraph is a personal computer with an ftp client but no servers, so neither of the other systems can access it, but it can ftp to them. The subject nob is configured to provide NFS service to a set of clients that does not include the host toadflax, and both systems will exchange mail with any host and allow any host to use ftp.
At the micro level, access control matrices can model programming language accesses; in this case, the objects are the variables and the subjects are the procedures (or modules). Consider a program in which events must be synchronized. A module provides functions for incrementing (inc_ctr) and decrementing (dec_ctr) a counter private to that module. The routine manager calls these functions. The access control matrix is shown in Figure 2-3. Note that "+" and "" are the rights, representing the ability to add and subtract, respectively, and call is the ability to invoke a procedure. The routine manager can call itself; presumably, it is recursive.
In the examples above, entries in the access control matrix are rights. However, they could as easily have been functions that determined the set of rights at any particular state based on other data, such as a history of prior accesses, the time of day, the rights another subject has over the object, and so forth. A common form of such a function is a locking function used to enforce the Bernstein conditions, so when a process is writing to a file, other processes cannot access the file; but once the writing is done, the processes can access the file once again.
|
