 |
NCSC-TG-020-A
|
| user1.projA | rw- |
| user2.projB | r-- |
| user3.* | rwx |
| *.projA | r-- |
| *.* | --- |
A database of tapes is maintained in /etc/tapedata. The database administrator (DBA) of the database wishes to produce a utility to control access to this database.To begin with, there are some rules for dealing with the database. Some users should have read and write access, others just read access, and still others should have no access to the database. Readers should only see data about their own tapes. In addition, since other database utilities have poor error handling, all updates to the database need to be made in the correct format.
The DBA has written a utility named tapedb which can read and update the database. /etc/tapedata and tapedb both have the group tape associated with them, and tapedb has the set-group-id bit on. The DBA has also created an ACL for /etc/tapedata which contains the following entries:
| user1.tape | r-- |
| user2.tape | r-- |
| user3.tape | rw- |
| user4.tape | rw- |
| *.* | --- |
While this example suggests a useful application of user and group ACL entries, there are other ways to implement the example which do not require this ACL entry type functionality. As described in the following section, the same effect can be achieved through ACLs containing user or group entries.
Additionally, identification by a user and group pair is not used in a UNIX System. In some systems, a user is identified by a user-ID, group-ID pair. In Multics, for example, a user is identified by a user-ID, project-ID pair. where a project-ID is equivalent to a group-ID on the UNIX system. User1 in projA. on a Multics system, is distinct from userl in projB. Since Multics users do not have the capability to change groups9 the only way for a user to be identified with another project would be to log in with another group-ID. In UNIX systems, however. a user is really only identified by the user-ID. Also, a user can easily change group-ID through the newgrp command or be associated with several groups at the same time if using a system with multiple groups. Thus, controlling access for a user while in a specific group is not as useful in a UNIX system.
5.2 User Or Group Entries
A user or group entry contains a reference to either a specific user or a specific group, but only one at a time. Consider the following example, where u indicates the user class, g indicates the group class, and o indicates the other class:
| u: user1 | rw- |
| u: user2 | r-- |
| u: user3 | rw- |
| u: user4 | rw- |
| g: projA | r-- |
| g: projB | rw- |
| o: | rw- |
To address the protected subsystem implementation, consider again the tape database example described in the previous section. Rather than controlling access to the data, access can be controlled on two subprograms; one which reads data, the other which updates data. The ACL on the database, /etc/tapedata would be:
| g: tapereaders | r-- |
| g: tapewirters | rw- |
| o: | --- |
The user interface for access to the database is tapedb. The program tapedb is not setgid, however, it invokes two other programs, tapedb_read and tapedb_write, that are setgid. Only users allowed to read the database have execute permission on, tapedb_read, while only those allowed to update the database may execute tapedb_write. The ACL on tapedb_read would be:
| u: user1 | --x |
| u: user2 | --x |
| u: user3 | --x |
| u: user4 | --x |
| o: | --- |
The ACL on tapedb_write would be:
| u: user3 | --x |
| u: user4 | --x |
| o: | --- |
Thus, the same protected subsystem can be provided through ACLs of type user or group.
The main advantage of this scheme is that it provides more clarity for the user. This is considered to be a very important advantage as a user's understanding of such a mechanism is essential in promoting its correct usage. Additionally, this scheme removes the need for wildcard specifiers, thus eliminating the potential problems of picking an unused character as a specifier.
5.3 Recommendation
User or group entries in ACLs are recommended. Since there is no clear need for the user-group paired entry scheme and there are several advantages to the user or group scheme, the user or group scheme is the preferred alternative. Examples were examined which claimed to require the use of user-group paired entries. One such example deals with protected subsystems as described above. Protected subsystems, a useful and important feature in a trusted system, can be implemented through other means not requiring user-group paired entries. We have "found that this is a limited class of applications and may be implemented with the user or group scheme with minimal effort. For UNIX systems with multiple groups, the user and group scheme becomes more difficult when determining access. Additionally, the user or group scheme follows the idea in UNIX systems that a user is only identified by user-ID and gives no special meaning to what a user can do while only in a certain group. Finally, although simplicity is a very subjective measure, in comparing the two alternatives the advantage of simplicity outweighs the ability to specify both a user and a group in a single entry.
6. Relationship Of ACL And File Permission Bits
ACLs expand upon the discretionary access control facility which is already provided by the file permission bits. Although file permission bits do not meet the TCSEC class B3 requirement for DAC, they are sufficient for many uses and are the only mechanism available to existing applications. Existing applications that are security-conscious use file permission bits to control access. The relationship between the ACL and the file permission bits is important to existing programs in order to maintain compatibility. For example, use of chmod("object" 0) should continue to work, denying subsequent opens to an object. The following sections discuss possible approaches to handling the interaction of ACLs with file permission bits. Any references to default ACLs will be fully described in the Default ACLs section.
6.1 ACL Always Replaces File Permission Bits (Pure ACL)
In this approach, the file permission bits are no longer consulted for DAC decisions. Instead, each object always has an ACL and the ACL completely determines access.Consider the following example illustrating this scheme. Assume User1 and User2 are members of the group "GroupA" and User3 and User4 are not.
| File Owner/Group: | User2/GroupA |
| File Permission Bits: | rwxr-x--x |
| ACL Entries: | |
| User1 | rwx |
| User2 | r-- |
| User3 | rwx |
| User4 | --- |
In this example the file permission bits would have no effect on the access control decision. User3 is able to read, write and execute the file. User2 is able to read it, but not to execute or write to the file. The file permission bits are completely ignored.
The resulting pure ACL system does not have to worry about interactions between the ACL and the file permission bits, since the latter are not used for access control decisions. A single, well defined access policy is employed. Applications which should make use of DAC are forced to understand the new rules.
The major disadvantage of this scheme, however, is that compatibility is lost. Every DAC cognizant program, and that should be every program that manipulates the discretionary access control information on an object needs to be changed to understand ACLs.
6.2 Owner Selects ACL Or File Permission Bits
In this approach, either the file permission bits or the ACL are consulted for the access control decision on a per object basis. The owner determines whether the file permission bits or the ACL is used. The system call chmod returns an indicative error if the object has an ACL, but otherwise sets the file permission bits.Consider the two following examples which illustrate this approach. Once again assume User1 and User2 are members of the group "GroupA" and User3 and User4 are not.
Example A (ACL selected):
| File Owner/Group: | User2/GroupA |
| File Permission Bits: | rwxr-x--x |
| ACL Entries: | |
| User1 | rwx |
| User2 | r-- |
| User3 | rwx |
| User4 | --- |
Since there is an ACL on this file the access control is the same as in the previous example.
Example B (file permission bits selected):
| File Owner/Group: | User2/GroupA |
| File Permission Bits: | rwxr-x--x |
| ACL Entries: | NONE |
Since there are no ACL entries on this file the access control ~r determined by the permission bits. User2 (owner) has all access permissions to the file. User1 (a user in GroupA) is allowed read and execute access. User3 and User4 ("other" users) can only execute the file.
The resulting system behaves like a file permission bit based system if no one ever sets ACLs and like the pure ACL system if a default ACL mechanism is in use. Thus, either environment can be supported.
The compatibility issues raised in the previous section apply here as well. In addition, the programs have to determine which access control mechanism applies to each object created and set the DAC accordingly.
6.3 Independent ACL And File Permission Bits (AND)
In this approach, both the file permission bits and the ACL are consulted for the discretionary access control decision on a per object basis. Access is granted if and only if it is granted by both the ACL and the file permission bits.Consider the following example, which illustrates this approach. For this example, assume only User2 is in GroupA.
| File Owner/Group: | User2/GroupA |
| File Permission Bits: | rwxr-x--x |
| ACL Entries: | |
| User1 | rwx |
| User2 | r-- |
| User3 | rwx |
| User4 | --- |
In the example above, the file permission bits imply that User1 has execute permission, whereas the permissions specified in the ACL imply that User1 has full access. Without knowing which group User 1 is in, one cannot predict whether or not User1 can read the file. If User1 is in group GroupA, then User1 will have read and execute permissions. If User1 is not in group GroupA, then only execute permission will be granted. Similarly, without knowing User3's group, one cannot predict whether or not User3 has read access. User4 will have no possibility of access, due to no permissions specified in the ACL entry. As the example illustrates, there is no way to get a full ACL view with this scheme.
With this scheme, some compatibility is maintained. Calls to chmod have the desired effect from the restrictive point of view. ACL entries can further restrict access.
Making use of the ACL as the effective access control mechanism requires that the file permission bits be set wide-open (i.e., read, write, and execute bits are set for user, group and other). In situations where ACLs are not properly set, a new object will become generally accessible. Likewise, if the ACL is removed then the object will again be generally accessible. This scheme also allows for misleading status information given to programs which only use the existing mechanism.
6.4 Independent ACL And File Permission Bits (OR)
In this approach, both the file permission bits and the ACL are consulted for the discretionary access control decision on a per object basis. Access is granted if it is granted by either the ACL or the file permission bits. The ACL is used to grant access beyond what is set in the file permission bits.Consider the following example illustrating this approach. Assume only User2 is in GroupA.
| File Owner/Group: | User2/GroupA |
| File Permission Bits: | rwxr-x--x |
| ACL Entries: | |
| User1 | rwx |
| User2 | r-- |
| User3 | rwx |
| User4 | --- |
User1, User2, and User3 have read, write, and execute access. User4 has execute access.
Again, some compatibility is maintained. Calls to chmod have the desired effect from the permissive point of view. The previous alternative's problem of leaving the permission bits wide-open is thus avoided.
The problem with this scheme, however, is that a chmod call which would deny all access (chmod("object", 0)) in a system without ACLs will not do so here.
6.5 File Permission Bits Contained Within ACL
In this approach, only the ACL is consulted for discretionary access control decisions. The file permission bits are replaced by three "base" entries in the ACL. Calls to chmod modify the owner, group, and other entries contained in the ACL. Calls to stat read this information from the ACL.In the following two examples assume the owner entry is evaluated before additional user entries, and the group entry is evaluated before additional gr1oup entries.
Example A:
| File Owner/Group: | User2/GroupA |
| File Permission Bits: | rwxr-x--x |
| ACL Entries: | |
| owner | rwx |
| User1 | rwx |
| User2 | r-- |
| User3 | rwx |
| User4 | --- |
| group | --- |
| other | --- |
In this example. it is not clear what permissions User2 is to be granted, since a particular method for determining owner access has not been specified for the case where an additional user entry also names the owner. User2 could be granted read, write, and execute access as the owner. read access only, as per the explicit entry for User2, or some combination of the two (e.g., the AND or OR of the two). User1, User3, and User4 get their access from their ACL entries.
Example B: (After a chmod("object", 0))
| File Owner/Group: | User2/GroupA |
| File Permission Bits: | --------- |
| ACL Entries: | |
| owner | --- |
| User1 | rwx |
| User2 | r-- |
| User3 | rwx |
| User4 | --- |
| group | --- |
| other | --- |
Changing the file permission bits to zero does not change the permissions granted to User1, User3, and User4, since their access is based on ACL entries. User2's access may change depending on how owner access is determined when additional user entries naming the owner also exist.
If no additional entries are added to the ACLs, this system looks like a system without ACLs. The literal meaning of the file permission bits is preserved in the ACL.
As in the previous alternative, however, a chmod call which would deny all access (chmod("object", 0)) in a system without ACLs will not do so here.
6.6 ACL Masked By File Permission Bits
In this approach, both the file permission bits and the ACL are used for determining the discretionary access control decision. The access indicated in the ACL entry is logically ANDed (masked) with one or more of the file permission bit classes (file owner, file group, or file other class) to determine the effective DAC permission.Example:
| File Owner/Group: | User2/GroupA |
| File Permission Bits: | rwxr-x--x |
| ACL Entries: | |
| User1 | rwx |
| User2 | r-- |
| User3 | rwx |
| User4 | --- |
Assume that the group file permission bits are chosen as the mask, i.e., all ACL entries will be ANDed against the file group class permission bits. User2, being the owner, gets read, write, and execute access to the file. User3 is allowed read and execute access. User1 is allowed read and execute access, the write access is disallowed by the file permission bits. User4 is not allowed any access to the file.
Calls to chmod have the desired effect from the restrictive point of view but not necessarily from the permissive point of view. Since the bits of the masked field will most likely be set wide-open, the literal meaning of the field chosen for the mask appears to be lost. The POSIX standard, however, allows for the extended meaning of the group class permission. bits.
6.7 Recommendation
We recommend the ACL Masked By File Permission Bits approach. This is the most reasonable approach when trying to balance security and compatibility. The question of designating the masking field must still be resolved. The file group class permission bits are the preferred masking field, even though they encourage permissive default access by the owning group. This choice must be made because the use of the file owner class would cause compatibility problems in programs which attempt to establish "owner-only" access, whereas the designation of the file other class could leave objects open to attack were an ACL removed or never present. An additional option of masking user entries with the file owner class permission bits and group entries with the file group class permission bits has the same disadvantages as masking against only the file owner class. When masking against the file group class, the permissions indicate the least upper bound of the permissions allowed for the ACL entries and the user and other fields retain their previous semantics.To summarize the approaches identified in this section:
The ACL Masked By File Permission Bits approach is a compromise for both security and compatibility.
The Independent ACL And File Permission Bits (AND) approach suffers from the serious flaw that the file permission bits must be set very permissively in order to allow the ACL entries to predominate in the discretionary access calculation. A simple mistake in setting the ACL could grant object access to significantly more users than was intended.
The Independent ACL And File Permission Bits (OR) approach may require that both ACL and the file permission bits be changed in order to deny a particular access. Thus, existing programs could believe that they had prevented access when they, in fact, had not. Similarly, in the File Permission Bits Contained Within ACL approach, removing "other" permission might not have the desired effect9 since, the owner, group, and other entries may not be the only ones in the ACL. In neither case does a call to chmod with a zero argument unequivocally revoke access from all users as might be expected.
Whichever DAC scheme is ultimately selected, an appropriate balance must be struck between the mutually conflicting concerns of compatibility and security. In a DAC scheme where chmod cooperates with ACLs, chmod must not grant inappropriate access or require unreasonable (i.e., permissive public access) defaults.
Barring compatibility, the alternatives of ACLs replacing file permission bits (Pure ACLs and On Demand) would be the most elegant way of enhancing DAC for UNIX systems. By abandoning file permission bits, however, these schemes have been rendered incompatible with existing systems. Thus, they are not considered for a POSIX-compliant UNIX system DAC scheme.
7. Group Semantics
There are various ways of using the UNIX system group mechanism when grouping system users. In designing ACLs it is important to understand the possible semantics and provide enough flexibility to properly support these semantics. Initially, there are no restrictions on how users can be grouped. Various possibilities include:
- a shorthand way of referring to groups of subjects
- a method of grouping project work by group access rights
- privileged roles
- accountability (file ownership)
7.1 Single Group Membership
Under a single membership scheme, a user can only be a member of one specific group at any given time. All discretionary access checks will be made with respect to the user's OlD and a single GID. A user will only be able to change his/her group through the use of the newgrp command. This scheme is easy to implement and introduces no additional complexity with respect to evaluating access within an ACL. Additionally. it would certainly be acceptable in a class B3 system.
7.2 Multiple Concurrent Group Membership
Under a multiple concurrent group scheme, a user can be a member of more than one group at the same time. This scheme introduces some complexity when evaluating user access by allowing more than one ACL entry of equal specificity to apply to a user simultaneously. For example, if a user is a member of several groups at the same time and tries to access an object with an ACL containing entries which match the user on more than one group, what will the resulting access be? There ar several ways of determining the resulting access in such a case. These are discussed under ACL Evaluation.Another concern with the use of multiple concurrent groups is the possibility of violating the least privilege principle. With multiple concurrent groups if a user is in several groups at once, he/she is granted access to all of those groups at all times rather than to just the ones he/she needs at any given time. This could be contrary to the idea of a user having a minimal set of privileges necessary to perform a particular function at any given time.
It can be argued, however, that the least privilege requirement in the TCSEC only applies to TCB architecture, making this issue irrelevant for DAC. On the other hand there may be a problem with a system which implements privileged roles through the group mechanism. The TCSEC class B3 Trusted Facility Management requirement states that separate roles must be assigned to operator and administrator functions and that each role be restricted to performing only those functions necessary for that role. Given a system, therefore, which uses the group mechanism to assign roles and grant access based on role identity to parts of the system which would otherwise be inaccessible, it is clear that least privilege could be violated through the use of multiple concurrent groups. The violation would occur if the user who was a member of the group assigned to a privileged role could also be a member of one or more additional groups. Proper administration of these privileged groups, however. could still allow for the use of multiple groups. but a subsetting capability, as described in the next subsection, would then be required.
Improperly controlled multiple concurrent groups with groups representing privileged roles could therefore be a violation of the least privilege principle. This would result in a failure to meet the class B3 requirements. This is only one specific implementation, however, and it is certainly conceivable that multiple concurrent groups could be implemented in such a way as to not be a violation of least privilege. The multiple concurrent group scheme is currently a feature in some UNIX systems and is thought to be an extremely useful and necessary feature to those who use it. Multiple concurrent groups would also be compatible with the POSIX standard
7.3 Multiple Concurrent Groups With Subsetting
Another problem associated with multiple concurrent groups arises from the fact that currently when a user logs on to a system he/she automatically becomes a member of all of the groups that he/she is allowed membership in. There is no way for the user to only be active in a subset of his/her possible group set. Although there is no explicit requirement in the TCSEC precluding this, the TCSEC does seem to imply that a user should by default have a minimal amount of access rights at login.There are several ways of approaching this problem; any of these methods would be a possible and acceptable means of resolving this problem. First, it is necessary to consider whether a user should be able to add or delete groups from his/her group set and if so, with what restrictions. A user should certainly not be allowed to add groups for which he/she is not authorized. Therefore each user should have an "allowable group set" which consists of all groups that user has been given authorization to be a member of. Adding groups other than those which appear in this allowable group set would be unacceptable.
There are at least two ways to allow a user to work with a subset of his/her allowable group set. The first would be to keep the current scheme where a user becomes a member of all of his/her groups at login, but provide the user with a means (through some system call or command) to drop specific groups if desired and work as a member of some subset of his/her allowable group set. A command would allow a user the capability but require an explicit action to do so. A system call, on the other hand, would provide the means for restriction through a program which could be set up to run automatically for the user. This would mean, however, that the set of groups would either be hardcoded into the program or be set through some type of configuration file. Another possible approach would be to provide a mechanism that would cause a program's groups to be restricted when that program is executed. Although this eliminates the user having to remember to restrict his/her groups or having to hardcode a group set into a program, it would add further complexity to the system.
7.4 Recommendation
We recommend that the multiple concurrent group capability be provided along with some method of subsetting. The preferred method would be to only allow the user to become a member of one group at login and provide him/her with a means of dynamically adding/deleting to his/her working group set. This recommendation, of course, may conflict with implementations which use the group mechanism for privilege roles.
8. ACL Evaluation
This issue deals with how an ACL is evaluated to determine access rights of a subject to a particular object. There are several possible ordering methods for ACL evaluation, as well as several different ways to evaluate multiple group entries.Two levels of ordering must actually be considered when deriving an ACL evaluation scheme; the ordering of the classes (user, group, other), and then the ordering of the entries within each class.
8.1 Ordering Of Classes
It would certainly be possible to specify an ordering of any combination of the three classes, user, group, and other. However, since both the POSIX standard and all current UNIX systems specify a "user, then group, then other" ordering, (or most-to-least specific), when evaluating access with permission bits, this ordering should be maintained for ACLs as well.The method of evaluating an ACL in a most-to-least specific manner can be described as follows. The owner identity of the object is first checked against the effective identity of the subject. If there is a match the search stops. Next, a check is made against the owning group identity of the object and the effective group of the subject. If there is a match and the subject does not have multiple groups, the search stops. Otherwise the rest of the group entries are searched next. If the subject has multiple groups, the group entries are evaluated as presented in the Multiple Group Evaluation section, otherwise they are searched in order as the user entries are. Finally, if no user or group entries were found to match the effective identity of the subject, access is determined based on the other entry.
For the following discussion on the ordering of ACL entries9 it will be assumed that the classes will be ordered and follow this most-to-least specific regime.
8.2 User-Defined Ordering
In this method, entries are considered according to the ordering given by the user. The first entry as specified by the user is considered first, the second entry next, and soon.As long as the "user, then group, then other" order is followed, the only security relevant problem with this method occurs when evaluating group entries with multiple groups. If a user is a member of multiple groups and matches more than one of the group entries, the resulting access may be dependent upon the ordering of the group entries. See the Multiple Group Evaluation section for various possibilities. Unless all matching group entries are considered when determining access, the burden is placed on the user to correctly order the group entries.
This method may appear to be more convenient for users, however, it may require the user to have extensive knowledge of group membership. Additionally, it does not allow for very efficient access evaluation as discussed in the following section.
8.3 System-Defined Ordering
In this method, entries are considered according to a system-defined ordering. Although the user does not have the flexibility of choosing an arbitrary order of entries, a system-defined ordering gives consistency to ACLs throughout the system and may also allow for quicker access determination.The system may use any of a variety of ordering methods, two of which are alphabetical ordering by user or group name and numeric ordering by user or group ID. An ordering of lowest to highest UID or GID, or vice-versa, is recommended as it provides an efficient way to check for redundant entries. Redundant entries should not be allowed in an ACL.
It is important to mention that actual sorting need not be done by the kernel itself as long as the kernel enforces the specified ordering. In other words, the sorting can be achieved through the use of library routines. The ACL commands would automatically use the library sorting routines and users would also be encouraged to do so when writing their own programs which manipulate ACLs. When an ACL passed to the kernel, the kernel verifies that the entries are sorted or else a failure will occur. In this manner, efficiency is achieved while still enforcing a system-defined ordering.
This alternative is simple. reduces the possibility of user error, and allows for more efficient access determination.
8.4 Multiple Group Evaluation
When a subject is a member of multiple groups, there are several ways the group entries may be evaluated, regardless of the ordering of the entries.The following methods may be used to evaluate access when multiple groups are used:
The first entry which matches one of the subject's groups might be used to determine access. While this is an efficient method, it does not take notice of the possibility of other groups granting access.
The entry which matches one of the subject's groups and grants the least access might be used. This method does not recognize the possibility that all the groups together might grant or deny the desired access.
The entry which matches one of the subject's groups and grants the most access might be used. This method also does not recognize the possibility that all the groups together might grant or deny access.
ANDing the permissions of all the entries which match groups of the subject is another possible method. This approach may be considered too restrictive, since even one entry which grants access may be overruled by other entries which deny access.
ORing the permissions of all the entries which match groups of the subject is also a possibility. This method may be considered too permissive, since the maximum permissions allowed by all the matching entries taken together is the result. However, the same effect can be achieved currently, through the user simply invoking the newgrp command to change to the group with the d1esired access or by opening the same file twice from two different groups which together provide the desired access.
8.5 Recommendation
A system-defined ordering which evaluates ACLs entries from most-to-least specific is recommended. Since multiple groups were designed to be permissive and permissive results can be achieved through other means anyway, the method which ORs the permissions of all matching group entries is recommended for systems implementing multiple groups.Concern has been expressed that this scheme violates the wording in the TCSEC, for DAC at class B3. The TCSEC states: Furthermore, for each such named object, it shall be possible to specify a list of named individuals and a list of groups of named individuals for which no access to the object is to be given. The ORing of groups, however, does not present a conflict with the class B3 DAC requirement, as it still allows the user to specify groups that shall have no access.
9. DAC Compatibility
Designing an ACL mechanism requires that attention be given to the use of system calls which check or modify the existing DAC mechanisms, and to the additional use of ACL mechanisms in system calls. The classes of DAC mechanisms which return or change the value of the discretionary access control information are those mechanisms which: change ownership of an object, change the file permission bits, create objects, access object attributes. and access object data. Each of these classes will now be examined and a determination will be made of what changes, if any, are required for inclusion in a system with ACLs. For each class, we provide alternative solutions and identify the preferred choice.
9.1 Changing Ownership Of An Object
Mechanisms which change ownership of an object (e.g., chown, msgctl, semctl, shmctl) could create a new user or group entry for the object owner or group, with the same access permissions as the original entry for the object owner or group. The original entry would become an additional user or group entry. The problem with this alternative is that by leaving the original entry for the object owner or group behind as an additional user or group entry, the mechanism will always create an ACL for an object which did not have one to begin with.The preferred alternative is for these calls to suffer no additional side effects due to the presence of ACLs. This can be achieved by not storing explicit IDs in the owner and owning group ACL entries. An advantage of this alternative is that the ACL entries for object owner and object owning group can be readily distinguished syntactically from the other user and group entries.
9.2 Changing The File Permission Bits
Mechanisms which change the file permission bits (e.g., chmod, msgctl, semctl, shmctl) might be changed so that they fail, or partially fail, when presented with an object that has an ACL.Complete failure is a poor alternative since these mechanisms change the file mode, not just the file permission bits. For example, a program should be able to do a legitimate operation such as changing the setgid bit on any file.
Partial failure means that these mechanisms would make the requested changes but return an error value different from -1. This is a poor alternative for two reasons: it does not make good sense to succeed while returning failure. and programs often do not differentiate between error return values.
Other alternatives attempt to minimize surprises to the caller by changing ACL entries. The first of these alternatives is to mask the access permissions in all the object's additional entries. Access permissions for entries with specific user and specific group are ANDed with the supplied user and group access permissions. Access permissions for entries with only a specific user are ANDed with supplied permissions for the user, and permissions for entries with only a specific group are ANDed with supplied permissions for the group. While this meets POSIX requirements, programs that wish to change only the file mode (non-access) bits will have the masking occur as an undesirable side effect. Another alternative is to disable the additional entries. This implicitly requires a new mechanism to enable entries that have been disabled. POSIX requirements are also satisfied by this alternative, but the same problems exist as in the previous alternative; programs using these mechanisms to change the non-access file mode bits will have entries disabled as an undesirable side effect. Still another alternative is to delete the additional entries. This has similar advantages and disadvantages as ACL entry disabling. It is simpler since there is no need for an ACL entry enabling mechanism. Information given by the user, however, is deleted without warning.
The preferred method is to make no changes to these mechanisms. The mechanisms will affect only file permission bits and ACL entries for the object owner or group. While this does not provide non-ACL cognizant programs with expected results for operations on objects with ACLs, it is not perceived as a serious problem. This alternative is consistent with the preferred alternative for mechanisms which access object attributes as well (see below).
9.3 Creating Objects
Mechanisms which create or truncate objects (e.g., creat, open, mkfifo, mkdir, msgget, semget, shmget) should work as they currently do, except that they may create an ACL as part of the default ACL mechanism. Please refer to the section on default ACLs for more information. Note that default protection on newly-created objects will be accomplished via the umask and/or default ACLs.It may also be desirable to add other types of ACL features to mechanisms. For example, one might wish to add the capability during file creation to adopt a specific ACL. For changes of this type, parameters of existing mechanisms should not be changed, and new parameters should not be added. New mechanisms should be created which make use of existing ones. For example. creat may need to be modified to take ACLs into account, but the parameter list should not change. Instead of adding an ACL parameter to creat, a new system call (i.e. with some other name) should be used. which takes the ACL as a parameter and then uses creat.
9.4 Accessing Object Attributes
Mechanisms which access object attributes (e.g. stat, msgctl, semctl, shmctl) could be modified to fail when applied to an object with an ACL. This is an unacceptable alternative since these mechanisms return more information than simply the file mode. Thus. non-functionality would require a new mechanism to return the additional information for objects with ACLs.Another alternative is to find all the entries in the ACL that apply to the user-ID and group-ID of the subject, just like a permissive access check. Then OR all the associated permissions together, and return the results in the appropriate file permission bits (user, group, and other). While this alternative integrates the idea of ACLs into mechanisms that access object attributes9 the context of the mechanisms affects the result returned to the point where the meaning of what the mechanisms return is somewhat clouded.
The preferred alternative is to make no changes to these mechanisms. The mechanisms will continue to return the file permission bits as if ACLs did not exist. Another mechanism must then be used to find out if the file has an ACL, and if so, what its entries are. While this alternative does not provide all information to subjects that don't know about ACLs, it does not change the current behavior of these mechanisms.
9.5 Accessing Object Data
There are a number of system calls which will need to have AFL functionality added to them (i.e., for access checking). These calls include all those taking file system object names as parameters, as well as those IPC mechanisms which perform access checks. Examples of some of these calls are: open, msgsnd, msgrcv, semop, and shmat.It is also important for portability that programs use the available access control mechanisms in an appropriate manner, so that the security policy is interpreted correctly. For instance, at the system call level, the permission information returned by the use of stat may not be sufficient to determine allowed access; other information such as ACL contents may have to be evaluated as well.
9.6 Recommendation
The following is a summary of the preferred alternatives stated in this section. Regarding compatibility with existing DAC mechanisms that either 1) change ownership or group of an object. 2) change file permission bits, or 3) access object attributes should remain unchanged and not affect an existing ACL on the object or create an ACL where one did not exist before.Regarding the addition of ACL functionality, existing mechanisms should not be changed, and new parameters should not be added. Instead, new mechanisms should be created which make use of existing ones.
10. ACL System Calls And Commands
This issue addresses what the naming conventions and functionality for ACL system calls and commands should be.For system calls, there are at least two alternative types of designs. Each depends on how the ACL is viewed. In one approach, the ACL is a series of independent records which can be individually manipulated using calls similar to open, read, write, and close. This approach has a nice parallel to the way files are read and written, but may be viewed as overly complicated given the relative infrequency of ACL modification. In the other approach. the ACL is considered a single unit and is not changed record-by-record, but instead always manipulated as a whole. This approach uses a "get" and "set" concept for ACL operations, where an ACL, as a whole, is retrieved, modified locally, and then replaced [3]. This approach is simple and reflects the growing trend towards get/set type operations.
It may also be reasonable to extend the "get" and "set" concept to apply to default ACLs as well as to the ACL associated with an object. This is a natural extension of the way ACLs would be manipulated, and default ACL operations may be easily added to the recommended system call interface described below.
There are also two possible methods for implementing these calls. One option is to use separate system calls for each of the ACL operations (i.e., getacl, setacl). The other option is to have one ACL system call that can be invoked with a number of command arguments indicating the desired ACL operation [3]. An example of a useful additional command argument is one that would return the number of entries in the ACL. This method conserves the number of system calls, and provides the flexibility to add ACL commands via command arguments. Additionally, using this method, designers are free to implement library functions based on the system call with particular command flags.
For commands, the same issues apply as for system calls. In a system with ACLs, however, there will be a need for commands to not only manipulate ACLs, but also to show and manipulate all discretionary access control information. These commands should include. at a minimum:
- command(s) to retrieve and set file permission and mode bits (ls,
chmod)
- command(s) to retrieve and set ACL information (new)
- command(s) to retrieve effective discretionary access to files (new)
10.1 Recommendation
For the ACL system call interface, get/set ACL type operations should be used9 and should be implemented with a unified system call with command arguments used to implement the various operations. For commands. the names getacl and setacl are recommended since they follow from the get/set concept.
11. Named ACLs
A named ACL, as described in A Guide to Understanding Discretionary Access Control in Trusted Systems [2], is an ACL that can be shared or referred to by name. They may be implemented in one of two ways; either as a template copied into a user's ACL or shared through a pointer from the user's ACL space (shared ACL).A change to a shared ACL results in a change to the discretionary access on all objects using this ACL. This result may be considered to be a side-effect or a desired feature depending on the circumstance. Additionally, it may be difficult to determine which objects are sharing a specific named ACL, and a user may mistakenly grant access to an object that was not intended.
Another problem with named ACLs is that as objects they may themselves be required to contain discretionary access controls. This suggests the idea of recursive ACLs, a situation to be avoided.
11.1 Recommendation
Named ACLs need not be supported. but a system that does should be no less secure or less flexible than one that does not. Absolute flexibility of ACLs can be achieved, however, through the use of default ACLs as discussed in the following section. There is no strong case one way or the other for named ACLs. There are advantages and disadvantages to both alternatives and it would really depend on the environment as to whether named ACLs would be of any benefit.
12 Default ACLs
When considering ACLs, an issue arises as to whether a predesignated set of ACL entries should be assigned to an object automatically at the time of creation. The following alternatives present the possible ways to address this issue.
12.1 No Default ACLs
In this approach, no ACL is assigned at object creation time. The process umask will limit the file permission bits, as it currently does, to provide some default protection on an object.While this alternative maintains compatibility with existing programs, it is not a very practical solution. Depending on the relationship of the file permission bits and the ACL, the absence of default ACLs may not make sense. For instance, in a pure ACL implementation, the absence of default ACLs would result in no initial protection on newly created files. Additionally, this alternative would not encourage the use of ACLs by new programs, and would prevent ACL creation by old programs. ACLs could not propagate through the system and hence their usability would be lost.
12.2 Require Default ACLs
In this approach, an ACL would always be assigned at object creation time. This would allow for initial finer grained control on an object.Requiring default ACLs may cause incompatibilities for an old program that only looks at the file permission bits when it creates an object. Also, for many users, the umask may be a sufficient tool for limiting the permissions on an object when it is created. The main advantage of requiring default ACLs is that the usability of ACLs is greatly improved. Additionally, since an ACL is associated with an object in a single atomic operation, the possibility of a temporarily insecure state is avoided.
12.3 Provide Default ACLs
A mechanism is provided to put default ACLs on new objects. However9 not all new objects need to have default ACLs. This alternative allows specification of a default ACL, giving a finer granularity of access control than that provided by the file permission bits, and, at the same time allows, where desired, compatibility with existing programs.
12.4 Recommendation
Providing default ACLs and mechanisms to specify whether or not to use them is the best solution. This allows both classes of users, those who want default ACLs and those who do not (even those who want no ACLs at all), the flexibility to specify the scheme that they find most appropriate. Although in many cases the process umask would be sufficient to assign default permissions, systems and/or users making explicit use of ACLs will desire default ACLs. The default ACL scheme used should be straightforward to the user and should sensibly interact with the existing DAC mechanisms, including the umask mechanism. Note that even if an object is created with no default ACL, ACL entries may still be added to the object.This section has really only addressed default ACLs on file system objects. IPC objects are not part of the file system name space, and therefore require further consideration. IPC objects are relatively short lived. and are generally not manipulated by users at the command level as are files. Based on these characteristics default ACLs on IPC objects are probably not needed, and their use is not recommended.
13. Location Of Default ACLs
Consider the following possibilities for the origination of the default ACL.
13.1 System Wide
In this approach, one specific default ACL is assigned to any object created on the system by any subject. This is a very inflexible solution and misses the intent that discretionary access be set at the discretion of the user.
13.2 Per Process
In this approach, each user process defines a default ACL, similar to the umask currently used. This is a somewhat restrictive approach since this allows the user to set only a single set of defaults for all files created. It is likely that a user will wish to associate different default ACLs with files created for different projects. Additionally, the default ACL entries would have to be stored in the process area. The amount of process space required to hold the entries would vary based on the number of entries.
13.3 Per GID Of Created File
A default ACL could be associated with each GID. If GIDs are viewed as project identifiers, the effect is to associate a unique default ACL within each project subtree of the file system hierarchy. Further, in some UNIX Systems, where GIDs propagate to newly created objects based on the GID of the creating directory (rather than upon that of the creating subject), default protection very naturally distributes across the file system. However this variant imposes a somewhat restrictive viewpoint on the utility of groups.
13.4 Per Directory
This approach would allow the object's default ACL to originate from the containing directory of the object. A directory would contain both an ACL to be used for access checking and a default ACL to be used when a new object is created in the directory. All objects created in the directory would be assigned the default ACL. Newly created subdirectories would inherit the default ACL of the parent directory. In this manner, the default will propagate down through the file system structure resulting in much duplication of ACLs, possibly using much space. However, the utilization of such space is a small price to pay for enhanced security and usability, so the default should probably continue to propagate until the user takes some explicit action to stop the propagation.
13.5 Recommendation
A user typically arranges objects per directory representing project work or areas of interest. Since it is desirable, then, for similar objects to contain the same ACL, the per-directory approach becomes the preferred mechanism. Newly-created subdirectories should inherit the default ACL of the parent directory, so that defaults are propagated down the file system, unless explicitly turned off.
14. Interaction Of Default ACL Entries At File Creation
Currently, when a file is created a user can specify its initial permissions, however the access can be further restricted by the umask mechanism. The umask specifies the default protection bit settings when a file is created. Any bits set in the umask will be cleared in the bit settings on the newly created file. It is important, then, to consider how the default permission bit settings should interact with the entries in a default ACL.Consider the following options in the context of masking the ACL entries by the file group class permission bits as recommended in the ACL Evaluation section. Also note that these options are discussed with respect; to the ACL entry types as described in the ACL Entry Type and Format section. Additional mechanisms in the ACL which allow direct modification of the file group class permission bits at file creation are not precluded.
14.1 OR File Group Class Permission Bits
Add the default entries to the file and change the file group class permission bits to reflect the maximum permissions allowed in the ACL. This could result in more permission than was specified in the creation call. It is not reasonable to assume that the default permission bit settings can be ignored and completely overridden by the ACL. For example, if a default entry exists for user "fred" with the specified permissions of "rwx" but the file is not executable, then this permission should not be given.
14.2 AND File Group Class Permission Bits
Add the default entries to the file but change the permissions of the ACL entries so that they are no greater than the file group class permission bits. This is a reasonable alternative, but it may present a compatibility problem for some applications. An example of this problem would be when a C compiler creates a file. The file would not originally be created with execute permission, therefore no ACL entries on the file (which were default entries copied from the directory) would have execute permission. The last step for the compiler would be to make the file executable, however at this point, execute permission' which may have been specified in the default ACL entry is lost.
14.3 No Change To File Group Class Permission Bits
Add the default entries to the file but do not change the file group class permission bits. This may result in ACL entries which are restricted by the file group class permission bits.
14.4 Recommendation
The No Change To File Group Class Permission Bits is recommended since it is a reasonable alternative which does not present any problems of compatibility for some applications.
15. Summary
This document has provided an analysis of key issues involved in extending the discretionary access control in the UNIX system. For each of the issues identified, the paper has suggested alternative solutions, discussed the pros and cons of each, and then provided a recommendation.The following is a review of some of the important recommendations presented in the paper. An access control list mechanism was chosen to extend the current DAC mechanism. When considering the types of access provided in the UNIX system, additional access modes need not be defined, however they should also not be precluded. The recommended ACL entry type was that of user or group entries. The main advantages of this solution are conformance with the UNIX system method of identification through either the user-ID or the group-ID, and simplicity for the user. The method in which file protection bits and ACLs interact is a very important and complex issue given the conflicting goals of security and compatibility. The recommendation of masking the ACL entries by the group field of the protection bits was chosen as the most accommodating solution considering these goals. A system defined ordering of the ACL entries was preferred and it was recommended that the access allowed for a user in multiple groups should be the sum of all access allowed for each group represented in the ACL. Considering other multiple group issues9 it was recommended to provide the multiple concurrent group capability along with some method of subsetting. It was also recommended that default ACLs be provided and that they originate from the parent directory of the newly created object.
It is important to note that although these and other specific recommendations were given, it is certainly possible to design an acceptable class B3, POSIX-compliant UNIX system following some of the other alternatives. In fact, there are issues where the recommended solution may not be superior to another alternative and the designer should consider his/her own specific requirements when making a choice in those areas. It must also be pointed out that building a system following all the recommendations presented in this paper will not guarantee a full class B3 system. There are many additional class B3 requirements that go beyond the interface specification.
APPENDIX: Worked Example
A.1 Introduction and Overview
This worked example describes one particular Implementation following the recommendations in the TRUSIX rationale.
A.1.1 Discretionary Access Control
Discretionary access control (DAC) provides for the controlled sharing of objects (e.g., files, IPC objects) between subjects (e.g., processes). With discretionary access control, the owner of an object can grant permissions to other users. The discretionary access control mechanism uses object owner, object group, file permission bits (nine permission bits) and the access control list (ACL) of an object to determine the discretionary access to the object.This document will detail the DAC interfaces and their run-time behavior.
The goals of this ACL mechanism were:
- compatibility with the current UNIX System DAC mechanism and POSIX P1003.1
- user command interfaces that are easy to use and understand
- adhere to the "principle of least astonishment"
- interfaces should continue to work as expected
- chmod 000 file - no access to file
- chmod 700 file - only owner access to file
- chmod 444 file - denies write and execute access to file
- rwxrwxrwx
However, an ACL, which consists of one or more user entries, one or more group entries, one class entry, and one other entry, is not a constant length (in the following example, * indicates zero or more occurrences of the preceding entry type):
- # file: filename
- # owner: uid
- #group:gid
- user::rwx
- user:uid:rwx
- *
- group::rwx
- group:gid:rwx
- *
- class:rwx
- # owner: uid
- 1. the first 3 bits (high order) represent the file owner class and
define the permissions for the object owner,
- 2. the middle 3 bits (commonly called the group permission bits), represent the file group class. This class includes the owning group of the file and will be extended to include additional user and additional group ACL entries,
- 3. the last 3 bits (low order) represent the file other class and define the permissions for other (those that did not fall into 1 or 2 above).
- 2. the middle 3 bits (commonly called the group permission bits), represent the file group class. This class includes the owning group of the file and will be extended to include additional user and additional group ACL entries,
There is a direct mapping between the ACL and the file permission bits. Specifically, the file owner class permission bits will always be equal to the permissions of the ACL entry for the object owner (they may be the same bits depending upon the implementation). Additionally, the file other class permission bits will always be equal to the ACL other entry permissions. And the file group class permission bits will always be equal to the ACL class entry permissions. Typically, the file group class permission bits are set to the maximum permissions allowed to the additional user entries, the owning group entry, and the additional group entries.
Whenever a file is created on a file system that supports ACLs, the ACL will contain a user entry for the object owner, a group entry for the object owning group, a class entry for the file group class permissions, and an other entry for the rest of the world. For compatibility with the current mechanism, if the ACL contains no additional user or additional group entries, the permissions in the group entry for the object owning group and the class entry must be the same.
A.1.2 Use of Access Control Lists
The use of DAC with ACLs will be explained by comparing it to how a user of a non-ACL supporting UNIX System (as currently exists) would use DAC. To use the current DAC mechanism a user usually first executes ls -l and based on the output decides what the permissions must be changed to. in order to allow the desired access (for example the user may want to make the file executable, or only allow the owner to have write permission).EXAMPLE:
$ ls -l foo
-rw-rw-rw- 1 craig demo 53 Mar 6 17:37 foo
$ chmod 600 foo
$ ls -l foo
-rw------- 1 craig demo 53 Mar 6 17:37 foo
In the new DAC mechanism, using a pure ACL, there will be two new commands getacl and setacl (there will be a new function, acl, for which these commands provide a user interface). The getacl command will be used to display the ACL and the setacl command will be used to change the ACL.
These commands will be used in much the same way that Is and chmod are used. A user would first execute getacl to look at the ACL and then use setacl to make the desired changes. Because the ACL is not a fixed size, it may be difficult to manipulate. In order to simplify the use of ACLs the following example shows how the ACL may be easily manipulated using a text editor to give greater flexibility (note that changes may also be specified on the setacl command line).
EXAMPLE:
#the output of getacl is redirected to the file tmp
$ getacl bar > tmp
#the file tmp is edited and the line in italics is inserted
$ vi tmp
# file: bar
# owner: craig
# group: demo
user::rw-
group::rw-
group:guest:r--
class:rw-
other:rw-
#setacl is executed and the contents of the file tmp become the new
ACL for bar
$ setacl -f tmp bar
#the output from getacl for the file bar is displayed
$ getacl bar
# file: bar
# owner: craig
# group: demo
user::rw-
group::rw-
group:guest:r--
class:rw-
other:rw-
A.1.3 Structure of Access Control Lists
The ACL consists of the following types of entries, which must be in the following order:
- 1. user entry - This type of entry contains a user ID and
the permissions associated with it. There must always exist one entry
of this type, which will represent the object owner, and will be denoted
by a null (unspecified) user ID. There may be additional user
entries specified; however, no two additional user entries will
have the same user ID and there may not be any additional entries with
a null user ID. The term "additional user entries" will be used
to indicate all user entries except the entry for the object owner.
- 2. group entry - This type of entry contains a group ID and the permissions associated with it. There must always exist one entry of this type, which will represent the object owning group, and will be denoted by a null (unspecified) group ID. There may be additional group entries specified; however. no two additional group entries may have the same group ID and there may not be any additional entries with a null group ID. The term "additional group entries" will be used to indicate all group entries except the entry for the object owning group.
- 3. class entry - This type of entry contains the maximum permissions granted to the file group class. There is exactly one of these entries in an ACL.
- 4. other entry - This type of entry contains the permissions granted to a subject if none of the above entries have been matched. There is exactly one of these entries in an ACL.
- 5. default entry - This type of entry may only exist on a directory. These entries are similar to the entries described above, except that they are never used in an access check, but are used to indicate the non-default ACL entries that should be added to a file created within the directory. Default entries are optional, but no two default entries may have the same type and ID.
- 2. group entry - This type of entry contains a group ID and the permissions associated with it. There must always exist one entry of this type, which will represent the object owning group, and will be denoted by a null (unspecified) group ID. There may be additional group entries specified; however. no two additional group entries may have the same group ID and there may not be any additional entries with a null group ID. The term "additional group entries" will be used to indicate all group entries except the entry for the object owning group.
Entries in the user category shall be sorted numerically by user ID from lowest to highest, except for the object owner entry which always precedes all other user entries.
Entries in the group category shall be sorted numerically by group ID from lowest to highest, except for the object owning group entry, which always precedes all other group entries.
Entries in the default:user category shall be sorted numerically by user ID from lowest to highest, except for the default object owner entry, which always precedes all other default user entries. Entries in the default:group category shall be sorted numerically by group ID from lowest to highest, except for the default object owning group entry, which always precedes all other default group entries. The proper ordering of entries required by the acl function can be obtained by the use of the aclsort function. ACL entries given as input to the setacl command need not be sorted; the sorting will be performed by the setacl command.
The permissions that may be specified in an ACL entry are read(r), write(w), and execute/search(x).
When the setacl command is executed, the file owner class permission bits will be set to the permissions specified for the owner and the file other class permission bits will be set to the permissions specified for other. As an option, the file group class permission bits will be manipulated such that they reflect the maximum permission that the ACL permits to members of the file group class (any ACL entry other than the object owner or other). Otherwise, the file group class permission bits will be set to the permissions specified by the class entry. Therefore, if the file group class only allows read permission then additional user entries and any group entries in the ACL will not grant write or execute permission.
This ACL scheme supports finer discretionary access controls than the current mechanism, while maintaining compatibility with the current permissions mechanism. The DAC information may be changed in one atomic operation, avoiding the possibility of an intermediate insecure state. Finer controls can be specified via the ACL, including explicit specification of users disallowed any access to the object. Additionally, the file permission bits provide a summary of all access rights.
Rationale: The ACL scheme described here will allow entries to be either permissive or restrictive. In general, an entry that results in less permission than the file other class permissions would grant would be considered restrictive. An entry that results in more permission than the file other class permissions would grant would be c