Our model of protection can be viewed abstractly as a matrix, called an access matrix. The rows of the access matrix represent domains, and the columns represent objects. Each entry in the matrix consists of a set of access rights. Because the column defines objects explicitly, we can omit the object name from the access right. The entry access(i,j) defines the set of operations that a process executing in domain Di can invoke on object Oj.
Lets illustrate these concepts
- we consider the access matrix shown in Figure 14.3. There are four domains and four objects—three files (F1, F2, F3) and one laser printer. A process executing in domain D1 can read files Fj and F3. A process executing in domain D4 has the same privileges as one executing in domain D1 but in addition, it can also write onto files F1 and F2.
- Note that the laser printer can be accessed only by a process executing in domain Do The access-matrix scheme provides us with the mechanism for specifying a variety of policies. The mechanism consists of implementing the access matrix and ensuring that the semantic properties we have outlined indeed, hold.
- More specifically, we must ensure that a process executing in domain Dj can access only those objects specified in row \, and then only as allowed by the access-matrix entries. The access matrix can implement policy decisions concerning protection. The policy decisions involve which rights should be included in the (i,j)th entry. We must also decide the domain in which each process executes. This last policy is usually decided by the operating system.
- The users normally decide the contents of the access-matrix entries. When a user creates a new object Oj, the column 0j is added to the access matrix with the appropriate initialization entries, as dictated by the creator.
- The user may decide to enter some rights in some entries in column / and other rights in other entries, as needed. The access matrix provides an appropriate mechanism for defining and implementing strict control for both the static and dynamic association between processes and domains. When we switch a process from one domain to another, we are executing an operation (switch) on an object (the domain).
- We can control domain switching by including domains among the objects of the access matrix. Similarly, when we change the content of the access matrix, we are performing an operation on an object: the access matrix.
- Again, we can control these changes by including the access matrix itself as an object. Actually, since each entry in the access matrix may be modified individually, we must consider each entry in the access matrix as an object to be protected.
- Now, we need to consider only the operations possible on these new objects (domains and the access matrix) and decide how we want processes to be able to execute these operations.
- Processes should be able to switch from one domain to another. Domain switching from domain Di to domain Dj is allowed if and only if the access right switch e access(i,j). Thus, in Figure 14.4, a process executing in domain D2 can switch to domain D3 or to domain D4. A process in domain D4 can switch to D], and one in domain D\ can switch to domain D2.
- Allowing controlled change in the contents of the access-matrix entries requires three additional operations: copy, owner, and control. We examine these operations next.
- The ability to copy an access right from one domain (or row) of the access matrix to another is denoted by an asterisk (*) appended to the access right. The copy right allows the copying of the access right only within the column (that is, for the object) for which the right is defined. For example, in Figure 14.5(a), a process executing in domain D2 can copy the read operation into any entry associated with file F2. Hence, the access matrix of Figure 14.5(a) can be modified to the access matrix shown in Figure 14.5(b).
- This scheme has two variants:
1. A right is copied from access(i,j) to access(k,j); it is then removed from access(i,j). This action is a transfer of a right, rather than a copy.
2. Propagation of the copy right may be limited. That is, when the right R* is copied from access(i,j) to access(k,j), only the right R (not R") is created. A process executing in domain Dk cannot further copy the right R.
- A system may select only one of these three copy rights, or it may provide all three by identifying them as separate rights: copy, transfer, and limited copy.
- We also need a mechanism to allow addition of new rights and removal of some rights. The owner right controls these operations. If access(i,j) includes the owner right, then a process executing in domain Di can add and remove any right in any entry in column j.
- For example, in Figure 14.6(a), domain D1 is the owner of F1 and thus can add and delete any valid right in column F1.
- Similarly, domain D2 is the owner of F2 and F3 and thus can add and remove any valid right within these two columns. Thus, the access matrix of Figure 14.6(a) can be modified to the access matrix shown in Figure 14.6(b).
- The copy and owner rights allow a process to change the entries in a column. A mechanism is also needed to change the entries in a row.
The control right is applicable only to domain objects. If access(i,j) includes the control right, then a process executing in domain Di. can remove any access right from row /'.
For example, suppose that, in Figure 14.4, we include the control right in access(D2, D4). Then, a process executing in domain D2 could modify domain D4, as shown in Figure 14.7. The copy and owner rights provide us with a mechanism to limit the propagation of access rights. However, they do not give us the appropriate tools for preventing the propagation (or disclosure) of information.
The problem of guaranteeing that no information initially held in an object can migrate outside of its execution environment is called the confinement problem. This problem is in general unsolvable (see Bibliographical Notes for references).
These operations on the domains and the access matrix are not in themselves important, but they illustrate the ability of the access-matrix model to allow the implementation and control of dynamic protection requirements.
New objects and new domains can be created dynamically and included in the access-matrix model. However, we have shown only that the basic mechanism is here; system designers and users must make the policy decisions concerning which domains are to have access to which objects in which ways.