NCSC-TG-020-A
VERSION-1
NATIONAL COMPUTER SECURITY CENTER
TRUSTED UNIX WORKING GROUP (TRUSIX)
RATIONALE FOR
SELECTING
ACCESS CONTROL LIST FEATURES
FOR THE UNIX (R) SYSTEM
18 August 1989
NATIONAL COMPUTER SECURITY CENTER
FORT GEORGE G.
MEADE, MARYLAND 20755-6000
NCSC-TG-020-A
Library No. S-232,508
The National Computer
Security Center (NCSC) formed the Trusted UNIX Working Group (TRUSIX) in 1987 to
provide technical guidance to vendors and evaluators involved in the development
of Trusted Computer System Evaluation Criteria (TCSEC) class B3 trusted UNIX*
systems. The NCSC specifically targeted the UNIX operating system for this
guidance because of its growing popularity among the government and vendor
communities. By addressing the class B3 issues, the NCSC believes that this
information will also help vendors understand how evaluation interpretations
will be made at the levels of trust below this class.TRUSIX is making no attempt
to address the entire spectrum of technical problems associated with the
development of division B systems; rather, the intent is to provide examples of
implementations of those security features discernible at the user interface
that will be acceptable at this level of trust.
TRUSIX is not intended to be a standards body. nor does it intend to produce
a de facto standard to compete against POSIX. Additionally, the TRUSIX documents
are not to be construed as supplementary requirements to the TCSEC. The TCSEC is
the only metric against which the trustworthiness of an operating system will be
evaluated.
This document, "Rationale for Selecting Access Control List (ACL) Features
for the UNIX System," is the first in a series of companion documents being
produced by TRUSIX. The guidelines described in this document provide
alternative methods for implementing ACLs in the UNIX system.
Recommendations for revision to this guideline are encouraged and will be
reviewed periodically by the NCSC. Address all proposals for revision through
appropriate channels to:
- National Computer Security Center
- 9800 Savage Road
- Fort George G. Meade, MD 20755-6000
- Attention: Chief, Technical Guidleines Division
_________________________________ 18 August 1989
Patrick R. Gallagher,
Jr.
Director
National Computer Security Center
_______________
* UNIX is a registered trademark of AT&T
Special recognition
is extended to those members of the TRUSIX Working Group who participated in the
Access Control List Subcommittee. Members of this subcommittee were: Craig
Rubin, AT&T Bell Laboratories (Co-Chair); Holly Traxler, National Computer
Security Center (NCSC)/Institute for Defense Analyses (IDA) (Co-Chair); Bruce
Calkins, NCSC; and Casey Schaufler, Sun Microsystems. Recognition is also
extended to the following members of TRUSIX who provided input through
discussion and comments: Bernie Badger, Harris Corporation; Caralyn Crescenzi,
NCSC; Cynthia Irvine, Gemini Computers; Howard Israel, AT&T Bell
Laboratories; Frank Knowles. MITRE; James Menendez. NCSC; Dr. Eric Roskos, IDA;
Rick Siebenaler, NCSC, Lucy Stasiak, AT&T Bell Laboratories; Albert Tao,
Gemini Computers; Dr. Charles Testa, Infosystems Technology, Incorporated (ITI),
Mario Tinto, NCSC; Grant Wagner, NCSC; Larry Wehr, AT&T Bell Laboratories;
and Bruce D. Wilner, ITI.
Acknowledgment is also extended to the members of the POSIX P1003.6 Security
Subcommittee and to those members of the computer security community who
contributed their time and expertise by actively participating in the review of
this document.
The Trusted UNIX
Working Group (TRUSIX) has examined the issues surrounding implementation of
access control lists (ACLs) in the UNIX System and has identified a set of
recommendations for implementors of ACL features. These recommendations balance
issues of compatibility with existing applications, ease of use and
acceptability to the end user9 and architectural simplicity with the
requirements for systems evaluated according to the Trusted Computer System
Evaluation Criteria (TCSEC). The recommendations reflect the collected opinions
and analyses of the participating vendors, evaluators, and researchers regarding
implementation of ACL features.
The recommendations of TRUSIX with regard to ACLs are as follows:
- ACLs are required for files IPC objects, and UNIX system domain sockets.
Access control for sockets that use name spaces other than those local to the
UNIX system (UDP, TCP) must be addressed in the specification and evaluation
of the system involved, and are neither explicitly recommended nor exempted.
- Access modes specifiable via ACLs should include read, write, and execute;
other modes should be allowed to be added as desired, but no additional modes
should be required to be supported.
- Each ACL entry should specify permissions for either a user or a group,
but not both.
- Permissions granted by an ACL entry are masked by the group class file
permission bits.
- Multiple concurrent groups should be supported. In addition, some method
of group subsetting should be provided. It is recommended that this subsetting
allow the user to become a member of only one group at login time, then to
dynamically add groups to or delete groups from the working group set as
required.
- A system-defined ordering of ACL evaluation that evaluates from most
specific to least specific is recommended. Where multiple concurrent groups
are in use, and more than one matching group is found in the ACL, permissions
granted by all matching groups should be ORed together.
- Modifications to mechanisms that change ownership, change the file
permission bits, or access object attributes are not recommended.
- Existing mechanisms for object access, inquiry, and deletion should not be
changed, and new parameters should not be added. Instead, new mechanism should
be created that make use of existing ones. The interface for mechanisms that
create objects should not be changed, except for the possible creation of a
default ACL.
- For the new mechanisms that are added to support ACL operations, get/set
operations should be used. These operations should be implemented via a single
system call with command arguments to specify the various operations. For
commands at the user interface, the names getacl and setacl are recommended.
- Named ACLs need not be supported.
- Provision of default ACLs for file system objects is recommended, along
with a user-specifiable mechanism for indicating whether or not they should be
used.
- Provision of default ACLs for IPC objects is not recommended.
- Default ACLs should be provided on a per-directory basis. Newly-created
subdirectories should inherit the default ACL of the parent directory.
- When a new object is created and ACL entries are attached via a default
ACL, the file group-class permission bits are not affected unless an explicit
mechanism is provided.
The preceding list summarizes the
recommendations of the Trusted UNIX Working Group. The main body of this
document discusses the rationale for these recommendations and gives further
details of the recommendations themselves. The appendix, the TRUSIX ACL Worked
Example, gives an example of how these recommendations might be implemented.
CONTENTS
TRUSIX Task Force: Rationale For Selecting Access Control List
Features
For The UNIX System
The intent of this document is
to explore the issues involved in extending the UNIX System discretionary access
control (DAC) mechanism. DAC is a means of controlling access to an object based
on the identity of subjects and/or groups to which they belong. The controls are
discretionary in the sense that they are chosen by the object owner.
The DAC mechanism employed in the current UNIX System was designed for
efficiency, flexibility. and ease of use. This mechanism allows and encourages
the sharing of information, but at a very coarse granularity, via the use of
file permission bits. File permission bits are associated with three classes:
owner (sometimes referred to as "user"), group. and other. Access for each class
is represented by a three-bit field allowing for read, write, and
execute-permissions.
Several methods exist for allowing discretionary access control on objects.
These methods include capabilities, profiles. access control lists (ACLs),
protection bits, and password DAC mechanisms. The intent was to select a DAC
mechanism with finer granularity than the current file permission bits, while
maximizing the compatibility with both the current mechanism and POSIX P1003.1.
Review of the methods described in A Guide to Understanding Discretionary Access
Control in Trusted Systems(2), and of the desired outcome, point to the use of
ACLs. It should be noted that ACLs can be considered a straightforward extension
of the existing UNIX system protection bits, since the protection bits may be
interpreted to be a limited form of an ACL, which always contains three entries.
It has been suggested that the fine granularity of control provided by ACLs
may be simulated in UNIX systems by using the group mechanism. Groups are lists
of users which may be used to specify who may access a file. In the worst case9
all possible combinations of users would have to be represented in order to
fully implement these lists. This corresponds to (2**M-1) groups, where M is the
number of bits in the group-ID. Since the number of possible combinations of
users needed to implement this scheme for N users is (2"N-1), the maximum number
of users which could effectively utilize such a system would be limited to the
number of bits in the group-ID. This number (often 16 or 32) is an unreasonably
small number for most UNIX systems and the management of the groups by users
would be difficult. Also, this scheme does not allow for individual users in the
lists to have different access rights. All users in the group would be forced to
have the access rights given by the file group class permission bits. Some
differences in access rights could be simulated by using the file other class
permission bits, but not with the same functionality as provided by conventional
ACLs.
The DAC features explored in this rationale are based on the DAC features
requested by customers, the class B3 DAC requirements described in the DoD
Trusted Computer Systems Evaluation Criteria [1] (TCSEC), and the DAC mechanisms
used in existing trusted systems (e.g., Multics). Based on these inputs9 it has
been determined that the current DAC mechanism in the UNIX System is adequate
for most needs and that the only enhancement required is to allow reasonable,
finer-grained control of objects. This provides the capability to share or deny
access to individually specified users and/or groups and meets the class B3
requirements of the TCSEC.
The issues explored in this document will deal primarily with ACLs. Much of
the terminology has been adopted from the P1003.1 document and the TCSEC;
however, new terms will be defined when used. For most of the issues identified,
alternative solutions are given along with a recommendation. Although an attempt
was made to consider the' issues independently, it should be noted that sole of
the issues are actually very dependent on each other and recommendations `made
in some areas greatly influenced later recommendations.
_______________
* UNIX is a registered trademark of AT&T
The primary goal in extending
discretionary access control in the UNIX system is to provide a finer
granularity of control in specifying user and/or group access to objects. This
can be achieved through the addition of access control lists. The following is a
list of additional goals for the extended DAC mechanism:
- The mechanism should provide compatibility with the existing (currently
P1003.1) and emerging POSIX standards and with the current UNIX System DAC
mechanism. In the unlikely event of a conflict between the current UNIX System
DAC mechanism and POSIX, the POSIX interpretation will be used. In addition,
the semantics of existing interfaces should be maintained.
- The following requirements for DAC in the TCSEC at class B3 should be
fulfilled. "The TCB shall define and control access between named users and
named objects (e.g., files and programs) in the ADP system. The enforcement
mechanism (e.g., access control lists) shall allow users to specify and
control sharing of those objects, and shall provide controls to limit
propagation of access rights. The discretionary access control mechanism shall
either by explicit user action or by default, provide that objects are
protected from unauthorized access. These access controls shall be capable of
specifying, for each named object, a list of named individuals and a list of
groups of named individuals with their respective modes of access to that
object. 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. Access permissions to an
object by users not already possessing access permission shall only be
assigned by authorized users."
- Reasonable vendor extensions to the DAC mechanism should not be precluded.
For example, the specification of read, write and execute permissions should
be supported. Other permissions should not be required nor should they be
precluded as extensions. A minimum set of new interfaces and error codes
should be provided. The new command interfaces provided for the user must be
easy to use and the existing interfaces should continue to work as expected.
- Intermixing use of the existing and newly-defined DAC functions/commands
should provide reasonable results. Security should be maximized by opting for
more restrictive rather than less restrictive decisions when a choice must be
made.
- When changing DAC on an object, at no time shall access be more permissive
than either the initial or resulting access.
A system can support several
different types of objects, e.g., system objects, public objects, named objects.
System objects are entities internal to the TCB (e.g., system data structures)
not directly accessible by the normal user and, as such, do not require
discretionary access control. Public objects are objects readable but
unmodifiable to the normal user (e.g., system clock) and thus also do not
require discretionary access control. Named objects are objects readable and
modifiable at the user interface (e.g., text files). The TCSEC class B3
requirement for DAC states that access control must be enforced on all named
objects in the system [1]. Although there may be some variance among different
UNIX system implementations, there are two common classes of named objects that
require ACLs. These classes are files (including regular. directory. special.
and named pipes), and named IPC objects (including shared memory, message
queues, semaphores, and sockets).
It is these classes of objects that will be protected by the discretionary
access control alternatives described later in the paper. It should be pointed
out, however, that discretionary access can not always be completely determined
solely by the file permission bits and the ACL associated with the object. It is
possible to have objects which have been administratively configured for a
specific access and thus not completely affected by user DAC, e.g., a file
system mounted read-only. There are other instances where discretionary access
of objects may be time-dependent and thus not completely based on a current DAC
setting. Examples of this would be the inability to write a shared-text file
while it is being executed or trying to execute a file while it is open for
writing. These situations are acknowledged special cases and will not be
considered in the general discussion of determining effective discretionary
access.
IPC objects are named
objects and are thus require ACLs at class B3. Note that this does not include
unnamed pipes which can only be used to connect related processes. Although the
semantics of IPC mechanisms are slightly different from those of file system
objects, a DAC scheme similar to that used for file system objects should easily
be adaptable to IPC objects. For example, message queues utilize both a creator
and an owner of an IPC object and maintain creator and owner UIDs and GIDs
(cuid,uid, cgid,gid). User access is checked against the cuid and the uid, and
group access is checked against the cgid and gid. This situation can easily be
represented with ACLs by using additional ACL entries to represent the creator
UID and GID. Additionally, some access modes associated with file system
objects, such as execute, may not be applicable to IPC objects. This does not
cause a problem as long as the modes are a subset of those defined for file
system objects.
Sockets are named objects
and would thus require ACLs at class 83. UNIX system domain sockets use the file
system name space for access control decisions and currently have file
permission bits associated with them. Thus, domain sockets would also need to
have ACLs associated with them. Other types of sockets which use other name
spaces (UDP. TCP) are currently not protected with any type of access control.
Since it is not clear whether these types of sockets could currently be included
in an evaluated configuration, they will not be addressed at this time.
Existing UNIX systems
support three access modes: read, write, and execute/search. Additional access
modes are conceivable, and may be convenient to add while adding ACLs. Various
possibilities include:
- read attributes of object
- write attributes of object
- append only to object
- truncate data of object
- delete object
- lock object
- restrict setuid execution of object
- restrict access of object based on time.
Note that this is not an
all-inclusive list.
In this and subsequent sections, alternative implementations of a given topic
are examined, followed by the TRUSIX recommendation.
In this
approach to handling additional access modes, new access modes would be defined
and required. This limits the availability of compliant implementations and
impacts compatibility.
In this
approach, new access modes would explicitly not be allowed. Due to loss of
flexibility, compliance with this scheme would limit implementation.
In this approach, new access modes would not be defined.
Instead. the concept of and mechanism for adding new access modes would be
defined. This allows a vendor to produce whatever additional access modes are
desired. Since the mechanism for doing so is defined there is little chance of
collisions or contradictions. The mechanisms must be defined and agreed upon by
some regulating body which allocates access bits. Note no such body currently
exists which has been tasked to allocate access bits.
In this approach, additional access modes are neither defined
nor precluded. This method allows a vendor to produce whatever additional access
modes are desired, but there is no mechanism provided for adding new modes.
There would be no control on the access modes vendors might add.
We recommend allowing
additional access modes, without control. There should be nothing precluding the
addition of new access modes if desired. However, since there is nothing
currently in the POSIX P1003.1 standard concerning additional access modes, no
new access modes or mechanisms need be defined.
The manner in which
an ACL entry refers to a user or group of users is an important factor in the
usability of an ACL mechanism. The alternatives are to have an ACL entry contain
either a user or group in an entry. or to have an ACL entry contain both a user
and group. The issue is which of the alternatives is more suitable to a system
utilizing ACLs.
A user and group
entry contains a reference to both a specific user and a specific group together
as a [UID,GID] pair. The UID-specific and GID-specific entries can be
represented as special "wildcard" cases (denoted by *) meaning any user or group
will match that entry. Using this method, an ACL entry may refer to one user in
a particular group [UID,GID], one user in any group [UID,*], any user in a
particular group [*,GID], or any user in any group [*,*] which is equivalent to
the file other class permission bits. A typical ACL