CASSIO: Why, no. The day had brokeBefore we parted. I ha' made bold, Iago,To send in to your wife. My suit to herIs that she will to virtuous DesdemonaProcure me some accéss. | ||
| --The Tragedy of Othello, III, i, 32–36. | ||
Recall the access control matrix discussed in Chapter 2. As in the theoretical model, an implementation of the array and the commands to manipulate it provide a mechanism that the system can use to control access to objects. Unfortunately, there are several problems with a straightforward implementation. On a typical system, the number of subjects and objects will be sufficiently large that the matrix's size will use significant amounts of storage. Second, most entries in the matrix will be either blank (indicating no access) or the same (because implementations often provide a default setting). Third, the creation and deletion of subjects and objects will require the matrix to manage its storage carefully, adding to the complexity of this code.
Instead, several optimizations enable systems to use more convenient, and in some cases simpler, versions of the access control matrix. Access control lists and capabilities are variants based on the access control matrix that eliminate many of the problems mentioned above. Various organizations of these mechanisms lead to powerful controls such as the ring-based mechanism of Multics. A third mechanism, locks and keys, is based on cryptography and provides a powerful alternative. A fourth mechanism uses access control lists to implement an ORCON-like control.
An obvious variant of the access control matrix is to store each column with the object it represents. Thus, each object has associated with it a set of pairs, with each pair containing a subject and a set of rights. The named subject can access the associated object using any of those rights. More formally:
Definition 15–1. Let S be the set of subjects, and R the set of rights, of a system. An access control list (ACL) l is a set of pairs l = { (s, r) : s ∊ S, r ⊆ R }. Let acl be a function that determines the access control list l associated with a particular object o. The interpretation of the access control list acl(o) = { (si, ri) : 1 ≤ i ≤ n } is that subject si may access o using any right in ri.
One issue is the matter of default permission. If a subject is not named in the ACL, it has no rights over the associated object. On a system with many subjects, the ACL may be very large. If many subjects have the same right over the file, one could define a “wildcard” to match any unnamed subjects, and give them default rights.
Some systems abbreviate access control lists. The basis for file access control in the UNIX operating system is of this variety. UNIX systems divide the set of users into three classes: the owner of the file, the group owner of the file, and all other users. Each class has a separate set of rights.
Abbreviations of access control lists, such as those supported by the UNIX operating system, suffer from a loss of granularity. Suppose a UNIX system has five users. Anne wants to allow Beth to read her file, Caroline to write to it, Della to read and write to it, and Elizabeth to execute it. Because there are only three sets of permissions and five desired arrangements of rights (including Alice), three triplets are insufficient to allow all desired modes of access. Hence, Alice must compromise, and either give someone more rights than she desires or give someone fewer rights. Similarly, traditional UNIX access control does not allow one to say “everybody but user Fran”; to do this, one must create groups of all users except Fran. Such an arrangement is cumbersome, the more so because only a system administrator can create groups.
Many systems augment abbreviations of ACLs with full-blown ACLs. This scheme uses the abbreviations of ACLs as the default permission controls; the explicit ACL overrides the defaults as needed. The exact method varies.
Specific implementations of ACLs differ in details. Some of the issues are as follows.
Which subjects can modify an object's ACL?
If there is a privileged user (such as root in the UNIX system or administrator in Windows NT), do the ACLs apply to that user?
Does the ACL support groups or wildcards (that is, can users be grouped into sets based on a system notion of “group” or on pattern matching)?
How are contradictory access control permissions handled? If one entry grants read privileges only and another grants write privileges only, which right does the subject have over the object?
If a default setting is allowed, do the ACL permissions modify it, or is the default used only when the subject is not explicitly mentioned in the ACL?
Because these isues are critical to the correct use of ACLs on a system, we will explore them in more detail.
When an ACL is created, rights are instantiated. Chief among these rights is the one we will call own. Possessors of the own right can modify the ACL.
Creating an object also creates its ACL, with some initial value (possibly empty, but more usually the creator is initially given all rights, including own, over the new object). By convention, the subject with own rights is allowed to modify the ACL. However, some systems allow anyone with access to manipulate the rights.
Many systems have users with extra privileges. The two best known are the root super-user on UNIX systems and the administrator user on Windows NT and 2000 systems. Typically, ACLs (or their degenerate forms) are applied in a limited fashion to such users.
In its classic form, ACLs do not support groups or wildcards. In practice, systems support one or the other (or both) to limit the size of the ACL and to make manipulation of the lists easier. A group can either refine the characteristics of the processes to be allowed access or be a synonym for a set of users (the members of the group).
A conflict arises when two access control list entries in the same ACL give different permissions to the subject. The system can allow access if any entry would give access, deny access if any entry would deny access, or apply the first entry that matches the subject.
When ACLs and abbreviations of access control lists or default access rights coexist (as on many UNIX systems), there are two ways to determine access rights. The first is to apply the appropriate ACL entry, if one exists, and to apply the default permissions or abbreviations of access control lists otherwise. The second way is to augment the default permissions or abbreviations of access control lists with those in the appropriate ACL entry.
Revocation, or the prevention of a subject's accessing an object, requires that the subject's rights be deleted from the object's ACL.
Preventing a subject from accessing an object is simple. The entry for the subject is deleted from the object's ACL. If only specific rights are to be deleted, they are removed from the relevant subject's entry in the ACL.
If ownership does not control the giving of rights, revocation is more complex.
Windows NT provides access control lists for those files on NTFS partitions [859]. Windows NT allows a user or group to read, write, execute, delete, change the permissions of, or take ownership of a file or directory. These rights are grouped into commonly assigned sets called generic rights. The generic rights for files are as follows.
no access, whereby the subject cannot access the file
read, whereby the subject can read or execute the file
change, whereby the subject can read, execute, write, or delete the file
full control, whereby the subject has all rights to the file
In addition, the generic right special access allows the assignment of any of the six permissions.
Windows NT directories also have their own notion of generic rights.
no access, whereby the subject cannot access the directory
read, whereby the subject can read or execute files within the directory
list, whereby the subject can list the contents of the directory and may change to a subdirectory within that directory
add, whereby the subject may create files or subdirectories in the directory
add and read, which combines the generic rights add and read
change, whereby the subject can create, read, execute, or write files within the directory and can delete subdirectories
full control, whereby the subject has all rights over the files and subdirectories in the directory
As before, the generic special access right allows assignment of other combinations of permissions.
When a user accesses a file, Windows NT first examines the file's ACL. If the user is not present in the ACL, and is not a member of any group listed in the ACL, access is denied. Otherwise, if any ACL entry denies the user access, Windows NT denies the access (this is an explicit denial, which is calculated first). If access is not explicitly denied, and the user is named in the ACL (as either a user or a member of a group), the user has the union of the set of rights from each ACL entry in which the user is named.
As an example, suppose Paul, Quentin, and Regina are users of a Windows NT system. Paul and Quentin are in the group students. Quentin and Regina are in the group staff. The directory e:stuff has its access control list set to (staff, add), (Quentin, change), (students, no access). Under this list, the first entry enables Regina to create subdirectories or files in e:stuff. The third entry disallows all members of the group students from accessing the directory. The second entry would allow Quentin to delete subdirectories, except that Quentin is in the students group, and in Windows NT an explicit deny (as given in the third entry) overrides any grants of permission. Hence, Quentin cannot access the directory.
Now, let Regina create a subdirectory plugh in e:stuff. She then disallows Paul's access, but wants to allow Quentin to have change access. She does the following.
Create e:stuff plugh; its ACL is (staff, add), (Quentin, change), (students, no access).
Delete the last entry in ACL; from the second entry, this gives Quentin change access.
Add the entry (Paul, no access) to the ACL.
The last step is superfluous, because Windows NT denies access by default, but it is safer to add it anyway, lest the group students be given rights. If that should happen, Paul would get those rights unless the (Paul, no access) entry were present.
Conceptually, a capability is like the row of an access control matrix. Each subject has associated with it a set of pairs, with each pair containing an object and a set of rights. The subject associated with this list can access the named object in any of the ways indicated by the named rights. More formally:
Definition 15–2. Let O be the set of objects, and R the set of rights, of a system. A capability list c is a set of pairs c = { (o, r) : o ∊ O, r ⊆ R }. Let cap be a function that determines the capability list c associated with a particular subject s. The interpretation of the capability list cap(s) = { (oi, ri) : 1 ≤ i ≤ n } is that subject s may access oi using any right in ri.
We abbreviate “capability list” as C-List.
Capabilities encapsulate object identity. When a process presents a capability on behalf of a user, the operating system examines the capability to determine both the object and the access to which the process is entitled. This reflects how capabiliies for memory management work; the location of the object in memory is encapsulated in the capability. Without a capability, the process cannot name the object in a way that will give it the desired access.
The “codewords” of Iliffe [509, 510] are similar to capabilities. Dennis and Van Horn [283] first suggested “capabilities” as a way to control access to objects in memory or secondary storage. Fabry generalized this idea to implement capability-based addressing [336].
The architecture of capabilities is more interesting than that of access control lists. The access control list and the process identity are under the control of the operating system. In the absence of flaws, user processes can change them only by invoking the operating system services. However, a process must identify a capability in order to use it, so the process must have some control over the capabilities. If the process can forge a capability and then use it, access controls fail.
Three mechanisms are used to protect capabilities: tags, protected memory, and cryptography.
A tagged architecture has a set of bits associated with each hardware word. The tag has two states: set and unset. If the tag is set, an ordinary process can read but not modify the word. If the tag is unset, an ordinary process can read and modify the word. Further, an ordinary process cannot change the state of the tag; the processor must be in a privileged mode to do so.
More common is to use the protection bits associated with paging or segmentation. All capabilities are stored in a page (segment) that the process can read but not alter. This requires no special-purpose hardware other than that used by the memory management scheme. But the process must reference capabilities indirectly, usually through pointers, rather than directly.
A third alternative is to use cryptography. The goal of tags and memory protection is to prevent the capabilities from being altered. This is akin to integrity checking. Cryptographic checksums are another mechanism for checking the integrity of information. Each capability has a cryptographic checksum associated with it, and the checksum is digitally enciphered using a cryptosystem whose key is known to the operating system.
When the process presents a capability to the operating system, the system first recomputes the cryptographic checksum associated with the capability. It then either enciphers the checksum using the cryptographic key and compares it with the one stored in the capability, or deciphers the checksum provided with the capability and compares it with the computed checksum. If they match, the capability is unaltered. If not, the capability is rejected.
The ability to copy capabilities implies the ability to give rights. To prevent processes from indiscriminately giving away rights, a copy flag is associated with capabilities. A process cannot copy a capability to another process unless the copy flag is set. If the process does copy the capability, the copy flag may be turned off (at the discretion of either the process or the kernel).
When holly uses the capability, the server notes that at least one bit in the rights field is 0. It takes the rights field, xor's it with the random number of the original capability (stored in its tables), and hashes the result. If the resulting hash matches the random number in the capability, the capability is valid; otherwise, it is not.
Amplification is the increasing of privileges. The idea of modular programming, and especially of abstract data types, requires that the rights a process has over an object be amplified.
To understand why, consider the following abstract data type for a counter.
module counter;
procedure entry increment(var ctr: integer);
begin
ctr := ctr + 1;
end;
function entry getval(ctr: integer);
begin
getval := ctr;
end;
procedure entry clear(var ctr: integer);
begin
ctr := 0;
end;
end.
Suppose x is declared to be a counter. The rules of abstract data types allow that object to be accessed only by the counter module. So, initially the capability for x would contain the right to invoke the counter module only. But when the object is passed to the counter module, the process must now be able to read and write to that object. Hence, the capability must be amplified temporarily while the module counter is active.
In a capability system, revoking access to an object requires that all the capabilities granting access to that object be revoked. Conceptually, each process could be checked, and the capabilities deleted. The cost of such an operation would be unacceptable, however, so alternative methods are used.
The simplest mechanism is indirection [833]. Define one or more global object tables. In this scheme, each object has a corresponding entry in a table. Capabilities do not name the object directly; they name the entry in the table corresponding to the object.
This scheme has several advantages. First, to revoke capabilities, the entry in the global object table is invalidated. Then any references will obtain an invalid table entry and will be rejected. Second, if only some of the capabilities are to be revoked, the object can have multiple entries, each corresponding to a different set of rights or a different group of users.
An alternative revocation mechanism uses abstract data type managers. Included with each abstract data type is a revocation procedure. When access is to be revoked, the type manager simpy disallows further accesses by the subject whose rights are being revoked. This does not affect alternative methods of accessing the objects underlying the abstract data types. For example, access to a file may be revoked, but this technique would not block access to the underlying segments through an alternative type manager. The SCP3 system used this technique [1054].
Boebert [124] credits Neumann and his colleagues [773] with a demonstration of the importance of controlling the copying of capabilities. Without such restrictions, a capability system cannot enforce the *-property of the Bell-LaPadula Model (see Chapter 5).
Suppose capabilities can be copied into one's C-List. Let Heidi be cleared for HIGH information, and Lou only for LOW information. The file “lough” has LOW classification. Lou asks for a capability to read and write to the file “lough” and obtains it (call the capability “rw*lough”). Lou stores the capability in the file “lough.” Now, Heidi requests a capability to read “lough” (call it “r*lough”); by the simple security condition, this is granted. Heidi uses this to read “lough,” thereby obtaining the capability “rw*lough.” She can now write to a LOW object, even though she has HIGH clearance. This violates the *-property. (See Figure 15-1.)
Figure 15-1. Copying and reading capabilities. In the left diagram, Lou has the capability rw*lough, which he copies into the file lough. Heidi obtains the capability r*lough. In the right diagram, Heidi has used her r*lough capability to read the contents of the file lough and has added the capability it contains to her C-List. She can now write to lough, violating the *-property. One solution is to separate the “copy” and “read” rights.
Kain and Landwehr [542] present two ways to handle this problem. Their first technique assigns a security classification to the capability itself. When the capability is created, its compartment is the same as the requesting process, and the capability contains read, read and write, or write rights depending on whether its compartment dominates, is the same as, or is dominated by that of the object to which the capability refers. Similar rules apply when a capability is copied. So, in Boebert's example, because the capability “rw*lough” is copied to HIGH, and because the destination (HIGH level) dominates the source (“lough,” at the LOW level), the resulting capability has only the right to read.
Their second solution uses a technique from Karger and Herbert [551], although in a different context. Before a capability is passed to another process, the kernel evaluates the capability to determine if passing it to the subject violates any security properties. In Boebert's example, the *-property is violated, so Heidi's request to obtain “rw*lough” would be denied.
A simpler approach is to distinguish between the “copy capability” right and the “read” right. The Take-Grant Protection Model (see Section 3.3) uses this difference to resolve Boebert's example. That Heidi could read the capability did not mean that she could acquire (take or copy) it. Heidi would be able to read the capability but could not add it to her C-List.
Two questions underlie the use of access controls:
Given a subject, what objects can it access, and how?
Given an object, what subjects can access it, and how?
In theory, either access control lists or capabilities can answer these questions. For the first question, capabilities are the simplest; just list the elements of the subject's associated C-List. For the second question, ACLs are the simplest; just list the elements of the object's access control list. In an ACL-based system, answering the first question requires all objects to be scanned. The system extracts all ACL entries associated with the subject in question. In a capability-based system, answering the second question requires all subjects to be scanned. The system extracts all capabilities associated with the object in question.
Karger and Herbert [551] speculate that the practical difference in answering the second question is the reason more systems use access control lists than capabilities. This question is asked more often than the first. As the focus of incident response (see Section 25.6, “Intrusion Response”) shifts from “who accessed the object” to include “what else did that subject access,” capability-based systems may become more common.
The locks and keys technique combines features of access control lists and capabilities. A piece of information (the lock) is associated with the object and a second piece of information (the key) is associated with those subjects authorized to access the object and the manner in which they are allowed to access the object. When a subject tries to access an object, the subject's set of keys is checked. If the subject has a key corresponding to any of the object's locks, access of the appropriate type is granted.
The difference between locks and keys and the other access control mechanisms is the dynamic nature of the former. An access control list is static in the sense that all changes to it are manual; a user or process must interact with the list to make the change. Locks and keys, on the other hand, may change in response to system constraints, general instructions about how entries are to be added, and any factors other than a manual change.
Gifford [392] suggests a cryptographic implementation of locks and keys. The object o is enciphered with a cryptographic key. The subject has a deciphering key. To access the object, the subject deciphers it. Gifford points out that this provides a simple way to allow n subjects to access the data (called or-access). Simply encipher n copies of the data using n different keys, one per subject. The object o is then represented as o´, where
o´ = ( E1(o), …, En(o))
The system can easily deny access except on the request of n subjects (called and-access). Simply iterate the cipher using n different keys, one per subject:
o´ = E1(…(En(o))…)
Type checking restricts access on the basis of the types of the subject and object. It is a form of locks and keys access control, the pieces of information being the type. Systems use type checking in areas other than security.
The simplest case of type checking is distinguishing instructions from data. The operation “execute” can be performed only on instructions, and the operations “read” and “write” can be performed only on data. Many systems, such as PDP-11 [297], enforce this distinction.
Like pages, files can be either “executable” or “data.”
Strictly enforced type checking is a powerful protection mechanism. The DTEL policy language discussed in Section 4.5.1, and the supporting domain and type enforcement (DTE) mechanism, are a good example. Walker et al. [1031] discuss the implementation of DTE using DTEL at length for the UNIX operating system. The Sidewinder firewall uses a similar approach.
A question related to the locks and keys access methods is how to construct a control that will allow any three out of ten people to gain access to a file.
This implements the principle of separation of privilege (see Section 13.2.6). A threshhold scheme provides this capability.
Definition 15–3. A (t, n)-threshhold scheme is a cryptographic scheme in which a datum is divided into n parts, any t of which are sufficient to determine the original datum. The n parts are called shadows.
The example above requires a (3, 10)-threshhold scheme to protect the decryption key (datum). The locks and keys scheme can solve this problem using a combination of or-access and and-access mechanisms, but the number of representations of the datum grows rapidly (see Exercise 7). An alternative is to use a cryptographic method designed to share secrets.
Shamir [907] based the first secret sharing algorithm on Lagrange interpolating polymonials. He selects a polynomial of degree t – 1 and sets the constant to the secret value. The shadows are the polynomial evaluated at an arbitrary point. By the laws of polynomial arithmetic, because the polynomial is of degree t – 1, at least t values are needed to rederive the polynomial.
Let P(x) = (at–1xt–1 + … + a1x + a0) mod p. The number we wish to share is S. Choose p to be greater than both S and n. Choose a0 = S; note that P(0) = S. Choose a1, …, at–1 arbitrarily. Then choose P(1), …, P(n) as the n shadows.
To recover the polynomial, we interpolate any t shadows. Let P(xi) = ki. The formula for the interpolated polynomial is
EXAMPLE: The people holding shadows 1, 2, and 5 decide to recompute the secret. Take x1 = 1, x2 = 2, and x3 = 5; this yields k1 = 4, k2 = 0, and k3 = 4. Recall that p = 11. Applying the formula above, we have
which yields
P(x) = [(x – 2)(x – 5) + 4(x – 1)(x – 2)] mod 11 = 5x2 + 3x + 7 mod 11
So the secret is P(0) = 7.
To protect a file using a secret sharing scheme, the system first enciphers the file. The cryptographic key then becomes the secret to be shared. If necessary, the key may be split into blocks of appropriate size, and each set of blocks shared using a secret sharing scheme. In theory, someone could share the contents of the file itself using a secret sharing scheme, but unless the file is very small, the benefits of sharing are outweighed by the problem of each user managing his or her own shadows for the file.
The Multics system [235, 788] generalizes the notion of a supervisor and user state with a protection mechanism called ring-based access control. To understand its simplicity and elegance, one must realize that files and memory are treated the same from the protection point of view. For example, a procedure may occupy a segment of the disk. When invoked, the segment is mapped into memory and executed. Data occupies other segments on disk, and when accessed, they are mapped into memory and accessed. In other words, there is no conceptual difference between a segment of memory and a segment on a disk.
Segments are of two kinds: data and procedure. A segment could have r (read) rights, w (write) rights, e (execute) rights, and a (append) rights associated with it. These rights are contained in access control lists, which constrain access on a per-user basis. So all procedures that user bishop executes would have the rights associated with that user, bishop.
In addition, the Multics system defines a sequence of protection rings (or rings, for short) numbered from 0 to 63.[1] The kernel resides in ring 0. The higher the ring number, the lower the privileges of the segments in that ring. We also say that “a procedure executes in ring r” because the ring is associated with the individual segment, not with the entire process.
Subject to the access constraints noted below, procedures can “cross” ring boundaries. In some cases, the crossing causes a “ring-crossing fault” that traps to the kernel. At that point, a mechanism called the Gatekeeper checks arguments and access and performs other functions that constrain ring crossings. In other cases, no ring-crossing fault is induced, and access is permitted if the access modes allow.
A gate is simply an entry point (like the “public” designators of object-oriented languages). Gates are specially declared within programs, and the compiler and linker generate special code to make these entry points available to other procedures.
Assume that a procedure executing in ring r wants to access a data segment. Associated with each data segment is a pair of ring numbers called an access bracket (a1, a2), with a1 ≤ a2. Assume that the data segment's permissions allow the desired access. The ring numbering adds an extra constraint:
r ≤ a1: access permitted
a1 < r ≤ a2: r and e access permitted; w and a access denied
a2 < r: all accesses denied
Assume that the same procedure, again executing in ring r, wants to access a procedure segment. Each procedure segment has an access bracket, just like a data segment. A procedure segment may also have a call bracket (c1, c2), with c1 ≤ c2. By convention, when a call bracket is present, c1 = a2, leading to an alternative notation of (a1, a2, a3), where (a1, a2) is the access bracket and (a2, a3) is the call bracket (that is, c2 = a3). The rules for access differ slightly from those for accessing a data segment:
r < a1: access permitted, but a ring-crossing fault occurs
a1 ≤ r ≤ a2: all accesses permitted and no fault occurs
a2 < r ≤ a3: access permitted if made through a valid gate
a3 < r: all accesses denied
The reason for the brackets shows how practical details complicate ideal solutions. Conceptually, the access bracket should contain one ring. However, consider a procedure embodying a service routine (such as “access file”). Then procedures in other rings accessing that routine would cause a large number of ring crossings. The operating system would need to handle these crossings, increasing the overhead. But if the procedures were within the service routine's access bracket, no ring-crossing faults would occur. Hence, the access bracket minimizes operating system overhead in this context.
A similar situation arises with different classes of users. Suppose a service routine lies in ring a. Some users need to invoke this routine. Others are allowed to invoke it in specific ways—for example, to access some system resource in a particular manner. Still others should not invoke it at all. The access bracket handles the first and third sets of users, but the second set cannot be handled with an access bracket. However, with a call bracket, the second set can access the service routine and be forced to use predefined entry points (the gates). Hence, the need for call brackets.
Variants of the ring mechanism have been used by other systems. The VAX system of Digital Equipment Corporation, for example, provides four levels of privilege: user, monitor, executive, and kernel. Contrast this with the more traditional two levels (user and supervisor) and the influence of the rings of Multics is clear.
The Propagated Access Control List (PACL) mechanism [1043] provides the creator of an object with control over who can access the object. It is an implementation that is ideal for the ORCON policy (see Section 7.3). The creator (originator) is kept with the PACL, and only the creator can change the PACL. When a subject reads an object, the PACL of the object is associated with the subject. When a subject creates an object, the PACL of the subject is associated with the object.
The notation PACLsubject means that subject is the originator of the PACL. Only subject can change that PACL. The notation PACL(entity) is the PACL associated with entity.
Let the PACL of an object o be PACLs. When another subject s´ reads o, PACL(o) must augment PACL(s´). Otherwise, s´ could create another subject o´, and copy the data from o to o´. Then s would have no control over the data in o, defeating the purpose of using PACLs.
Hence, an object can have PACLs associated with two creators. If so, both creators control access to the object. Only subjects common to both PACLs can access the object. Otherwise, one creator would not control access to the data it expects to control. The default is to deny access unless both creators allow it.
Discretionary access controls can augment PACLs. They restrict access, but they cannot allow access to subjects excluded by the PACL.
This example illustrates the distinction between the PACL mechanism and the ACL mechanism. A PACL is associated with data, whereas an ACL is associated with an object. The PACL follows the information as it flows around the system, but an ACL stays with each object. In the example, Cherisse cannot access the information in dates because of the setting of PACL(dates), and cannot access the information in any derivative of dates because PACL(dates) propagates with the information. The copiers of the information cannot change this.
Were the files protected by ACLs instead of PACLs, the ACL would not be copied with the information. So, Cherisse would not be able to read dates, but Betty could copy that file and set the ACL so that Cherisse could read it. Ann would not control the information; she would have to trust those with access to dates not to give access to others.
Access control mechanisms implement controls on subjects and objects. Access control lists bind the data controlling access to the object. Capability lists bind that data to the subject. Locks and keys distribute the data between the subject and the object. All are particularly well-suited for discretionary access controls, because usually the owners of the objects determine who gets access. If the controller of access is the operating system, then these mechanisms also can implement mandatory access controls.
Ring-based mechanisms generalize the notion of “monitor” and “user” mode. They are particularly well-suited for mandatory access controls, because the operating system enforces the barriers to ring crossings. However, the brackets must be chosen judiciously.
Propagated access control lists are associated with information rather than with the objects that contain the information. This makes them particularly suitable for implementing originator controlled policies.
Access control mechanisms provide ways of enforcing stated policies. How can these mechanisms work together to enforce policies? What limits do their natures impose on their use?
As an example, PACLs were created to provide a mechanism for enforcing ORCON policies. How can this mechanism be implemented in a manner that prevents users from compromising the system? Could other mechanisms enforce ORCON policies and be easier to implement?
Language-based techniques are seeing a resurgence. These techniques assert that compilers should add access-checking code to the programs. This technique is particularly well-suited for mobile code, where the operating systems may enforce different access control policies. The implications of the differences in policy between what a mobile program needs in order to perform its task, and how the system on which it is run limits its access, are under active study.
Proofs that the mechanisms supply security services sufficient to meet the goals of a system are another research issue. The method of noninterference and its related properties discussed in Chapter 8, “Noninterference and Policy Composition,” provide a basis for such proofs. Alternative techniques may be simpler and may take into account specific system details.
Finally, new or modified mechanisms may provide better control for particular policies or systems. This is also an area of research.
Saltzer [864] describes the use of access control lists in Multics. Kramer [593] describes their incorporation into the Linus system. Stiegler [972] describes structures used to implement ACLs. Riechmann and Hauck [838] discuss extensions. In addition to the systems described in this chapter, several others, both abstract and real, use capabilities [405, 452, 1022]. Klein [572] describes how to emulate capabilities using setuid programs in traditional UNIX systems. The KeyKOS system implemented capabilities [131, 447, 826], and its descendent, EROS [910, 911, 912], is revisiting the concepts. Ko [583] developed a model of the ring bracket mechanism and demonstrated that it can enforce either the Bell-LaPadula confidentiality policy or the Biba integrity policy, but not both. Blakley [121] and Asmuth and Bloom [44] discuss other secret sharing schemes. Simmons discusses several generalizations [924, 925, 926]. Others discuss several forms of cheating [147, 630, 997].