NATIONAL COMPUTER SECURITY CENTER
FORT GEORGE G. MEADE, MARYLAND 20755-6000
NCSC-TG-003-87
Library No. S-228,576
Recommendations for revision to this publication are encouraged and will be reviewed biannually by the NCSC through a formal review process. Address all proposals for revision through appropriate channels to:
_________________________________ 30 September 1997
Patrick R. Gallagher, Jr.
Director
National Computer Security Center
Carole S. Jordan, National Computer Security Center (NCSC), as primary author and preparer of this document. Dr. Deborah Downs, the Aerospace Corporation, who prepared an in-depth technical report on DAC mechanisms that became the major input to this document. Grant Wagner and Steve LaFountain, NCSC, who contributed their technical expertise and assistance throughout this effort. Dr. Dixie B. Baker, the Aerospace Corporation, who meticulously reviewed the document and suggested many changes.
Special thanks are extended to the many computer vendor representatives who enthusiastically gave of their time and technical expertise in reviewing the material and providing valuable comments and suggested changes. Among the vendor representatives who were so helpful were: Steven B. Lipner, Digital Equipment Corp., Dr. Roger Schell, Gemini Computers, Earl Boebert, Honeywell, Inc., and C.T. Bougas, Harris Corporation.
Discretionary controls are not a replacement for mandatory controls. In any environment in which information is protected, discretionary security provides for a finer granularity of control within the overall constraints of the mandatory policy. Both discretionary and mandatory controls can be used to implement an access control policy to handle multiple categories or types of information, such as proprietary, financial, personnel or classified information. Such information can be assigned different sensitivity designations and those designations enforced by the mandatory controls. Discretionary controls can give a user the discretion to specify the types of access other users may have to information under the user's control, consistent with the overriding mandatory policy restrictions. In a classified environment, no person may have access to classified information unless: (a) that person has been determined to be trustworthy, i.e., granted a personnel security clearance - MANDATORY, and (b) access is necessary for the performance of official duties, i.e., determined to have need-to-know - DISCRETIONARY. The discretionary security control objective is:
The identity of the users and objects is the key to discretionary access control. This concept is relatively straightforward in that the access control matrix, defined below, contains the names of users on the rows and the names of objects on the columns. Regardless of how the matrix is represented in memory, whether by rows or by columns, the names of the users and objects must be used in the representation. For example, in a row-based representation an entry might read the equivalent of ``KIM can access KIMSFILE and DONSFILE". In a column-based representation, one might find the equivalent of "DONSFILE can be accessed by DON, JOE and KIM".
Other Definitions:
access control matrix-a two-dimensional matrix representing users on the rows and objects on the columns. Each entry in the matrix represents the access type held by that user to that object. Access control matrices are usually sparsely populated and are represented in memory by row or by column, eliminating storage requirements for empty entries. Sea figure 1 in Section 7 for an example of an access control matrix.
access mode-entries in the access control matrix that specify certain operations a user may perform on an object, (e.g., read, write, execute, delete).
access permission-permission of a user to access an object in some manner. Entries in the access control matrix specify access permission. No access or "null" access may also be specified if desired.
control permission-a certain access mode that allows users to grant/revoke access permission and change access modes to objects. Sometimes this includes the ability to pass control permission to other users.
defined groups-groups which have been defined to the DAC mechanism before being used in access control decisions. Groups are normally defined by users with special privileges, such as the system administrator. A group should be defined by listing the identities of the members to be included in the group.
least privilege-this principle requires that each subject in a system be granted the most restrictive set of privileges needed for the performance of authorized tasks. The application of this principle limits the damage that can result from accident, error, or unauthorized use.
named users-users that are uniquely identified to the TCB. The unique identifier is to be used by the DAC mechanism to perform access control decisions.
object-a passive entity that contains or receives information. Access to an object potentially implies access to the information it contains. Examples of objects can be: records, blocks, pages, segments, files, directories, directory trees, and programs, as well as processors, video displays, printers, network interfaces, I/0 ports, etc.
ownership-a concept in which one user has total control over access to an object. A subject operating on behalf of that user is normally the creator of the object and is totally responsible for controlling access to it.
subject-an active entity, generally in the form of a process or device operating on behalf of a user that causes information to flow among objects or changes the system state. Technically, a process/domain pair.
Trojan horse-a computer program with an apparently or actually useful function that contains additional (hidden) functions that surreptitiously exploit the legitimate authorizations of the invoking process. An example is a program that makes a "blind copy" of a sensitive file for the creator of the Trojan horse.
Trusted Computing Base (TCB)The totality of protection mechanisms within a computer system - including hardware, firmware, and software - the combination of which is responsible for enforcing a security policy. A TCB consists of one or more components that together enforce a unified security policy over a product or system.
*-property--A Bell-LaPadula security model rule, called the "star*property," that allows a subject write access to an object only if the security level of the subject is dominated by the security level of the object. Also known as the Confinement Property.
DRAKE is determined to gain access to DOESFILE. He has legitimate access to the system which allows him to implement a useful utility program. In this utility DRAKE embeds a covert function to read DOESFILE and copy the `contents into a file in DRAKE's address space called DRAKESFILE. DRAKESFILE has an ACL associated with it that allows processes executing on DOE's behalf to write to it, while allowing DRAKE's processes to read it.
DRAKE induces DOE to execute his utility program by telling him how useful and efficient it is. DRAKE is careful not to tell DOE about the covert function (Trojan horse) that is resident in the utility program. DOE executes the corrupted program and it appears to perform perfectly. However, while it is operating on DOE's behalf, it assumes his identity and thus his access rights to DOESFILE. At this time it copies the contents of DOESFILE to DRAKESFILE. This copying takes place completely within the constraints of the DAC mechanism, and DOE is unaware of what is happening.
This example should make clear the danger of Trojan horse attacks and the inadequacy of most DAC mechanisms to protect against such attacks. It should be noted that an elaborate DAC mechanism may provide illusory security to users who are unaware of its vulnerability to Trojan horse attacks.
Configuration management, testing, and trusted distribution should ensure that software produced by the computer system manufacturer does not contain Trojan horses, especially if the system has a high EPL rating. However, software from other sources does not come with these assurances. In very high threat environments, it is wise to assume that unevaluated software does contain Trojan horses. This assumption dictates that discretionary access control not be used as the sole protection mechanism in high threat environments.
The Trojan horse threat can be reduced in systems that implement many domains or dynamic small domains for each process. In most systems today, with only user and supervisor domains, all of the user's objects are available to a process running on that user's behalf. If domains were created dynamically for each process, with only the necessary objects available in that domain (implementing the least privilege principle), then a Trojan horse would be limited to accessing only those objects within the domain [5], [7].
A reference monitor which implements a mandatory security policy which includes the *-property would provide robust protection against Trojan horse attacks. The mandatory access control implementation would prevent the Trojan horse from disclosing the information to a user who is not permitted access to the information under the mandatory access rules. Assume the same scenario as was described previously with the following changes. The computer system now implements a mandatory security policy with two hierarchical sensitivity levels. For the sake of simplicity, the levels are called sensitive and non-sensitive. DOE operates at the sensitive level, and DOESFILE is sensitive. DRAKE is not authorized to access sensitive data, so he operates at the non-sensitive level. DRAKE is only allowed to read non-sensitive files, so DRAKESFILE is non-sensitive. As before, DRAKE's Trojan horse program is executed by DOE. The program takes on the sensitivity level and the identity of DOE. Within the constraints of the mandatory and the discretionary security policies, the program reads DOESFILE. However, when the Trojan horse tries to write the sensitive data to DRAKESFILE, the reference monitor disallows the operation. Since the Trojan horse is now executing at the sensitive level, the program cannot be allowed to write to a non-sensitive file. That would be a violation of the *-property [1].
This example should show the reader that discretionary access control is only effective to restrict the ``honest'' user in browsing through other users' files and preventing accidental disclosure or destruction of information. The malicious user who is determined to gain unauthorized access to data on the computer system must be restricted by other means, such as mandatory access controls.
Implementing a complete DAC system requires retaining the information that is represented by the access control matrix model in some form. An access control matrix has users represented on the rows and protected objects on the columns (see figure 1). The entries in the matrix describe what type of access each user has to each object. Current operating systems have attempted to represent that information using five basic mechanisms:
ACCESS CONTROL MATRIX
| KIMSFILE | DONSFILE | PAYROL1 | PAYROL2 | DOESFILE | |
| Kim | rw | r | rw | r | |
| Joe | r | ||||
| Don | rw | r | |||
| Jones | r | r | |||
| Doe | rw | ||||
| MgrJim | cp | cp | c | c | |
| Jan | rw | rw |
Capabilities and profiles represent the access control matrix information by row, connecting the accessible objects to the user. ACLs and protection bits represent the access control matrix information by column, connecting a list of users to an object. As the balance of this section will demonstrate, ACLs are the most flexible and usable DAC mechanism that can be implemented with existing technology.
Capability-based systems [8] provide dynamically changeable domains (name spaces) for processes to run in. Ability to access an object is demonstrated when a process has a capability or "ticket" to the object. The capability also contains allowable access modes (e.g., read, write, execute). In some implementations, programs can contain capabilities or capabilities can be stored in files. They are protected by hardware and software mechanisms or by encryption. Capabilities can usually be passed along to other processes and can sometimes be increased or decreased in scope.
A pure capability system includes the ability for users to pass the capability to other users. Because this ability is not controlled and capabilities can be stored, determining all the users who have access for a particular object generally is not possible. This makes a complete DAC implementation, including revocation, very difficult. (Revocation may not be an issue, however, since a user who has access to an object can make a copy of the information in another object. Revoking the user's access on the original object does not revoke access to the information contained in the user's copy. After revocation, however, changes can be made to the original object without the knowledge of revoked users.) For a discussion on revokable capabilities see Redell's paper [9].
Since capabilities implement dynamic domains they can ideally limit the objects accessible to any program. This would limit a Trojan horse's access to only the protected objects handed to it. At this time, few systems have been implemented with capabilities and very few, if any, have attempted to implement a complete DAC mechanism. Some research has been conducted in restricting capabilities by overlaying a DAC mechanism [10].
Capabilities could be useful in enforcing the least privilege principle and providing dynamically changeable domains, making discretionary access controls less vulnerable to Trojan horse attacks. However, in order to pass the class C2 and above DAC requirements, the ability for users to pass capabilities to other users must be sufficiently controlled. There could be some design difficulties in building capability-based mechanisms to satisfy the B3 DAC requirement because of difficulty in implementing precisely defined groups [11]. Also, at class B3 it is required that users be able to specify a list of users that have permission (or do not have permission) to access each object. Capability-based systems are row-based mechanisms and do not easily lend themselves to this function. Deletion of an object from the system and revocation of access present yet another problem. The problem is that row-based systems do not provide an efficient means of determining which users have access to a given object.
Access to ACLs should be protected just as other objects are protected. The creation of groups must be controlled, since becoming a member of a group can change the objects accessible to any member. In many systems, e.g., Multics [14], a user must be a member of at least one group. One detriment of the group mechanism is that changing the members of a group results in changes to an unknown set of ACLs for protected objects. Allocation of groups could be a Systems Administrator function only, or it could be distributed to a Project Administrator type function. Problems could result from allowing any user to create a group and then be "owner'' of that group. If users were prohibited from listing the members of groups they are not in because of covert channels and privacy, it would be difficult to determine if a group was the correct one to use. System or Project Administrator control is a preferred mechanism.
A system-wide default could be used as the default in cases where no other default had been specified. A system-wide default might give access only to the creating user. A user-associated default might work well on a system with a flat file structure. When a user is first entered on the system, his default ACL would have to be specified.
For file structures that are trees, a default(s) associated with the directory could be most efficient. If the user organizes the directory structure to represent project work or areas of interest, then the ACLs for all objects in a sub-tree would be similar. One default ACL in the directory would be for children that are files. For children that are directories either a separate sub-directory default ACL should be specified or the default ACLs should have to be stated explicitly by the user. Otherwise, unless care is taken, those with access to the root sections of the storage hierarchy could by automatic default get access to all of the storage hierarchy. The overriding principle of least privilege implies that the use of defaults should not inadvertently give away more access than the user intended. In other words, to err on the conservative side is preferred. In all implementations some user(s) must have permission to change the ACLs after they have been set by default, and the ability to change the defaults is very useful. Defaults can be implemented in two ways: they can be copied to the ACL or they can be pointed to by the ACL. If they are copied, then changes to the default will not affect the ACL; otherwise, changes in the default may cause changes in many ACLs.
In summary, access control lists are the most desirable implementation of discretionary access control. ACLs conveniently lend themselves to specifying a list of named users who are allowed to access each object. Also, providing access to defined groups of users is easily done with ACL-based mechanisms. ACLs, if properly implemented, will satisfy the B3 DAC requirement. At class B1 and above, care must be taken so that the implementation does not conflict with mandatory controls.
The problem with protection bits is that they are an incomplete implementation of the access control matrix model. The system cannot conveniently allow or disallow access to a protected object on any single user basis. It has been suggested that groups be set up so that any needed combination of users can be specified. But, for more than a few users, the combinatorics of such a solution are unrealistic. Also, groups are controlled by the system administrator, and such a scheme would require full-time attention.
Many problems are associated with using a password protected DAC system. The use of passwords prevents the TCB from controlling distribution of access permissions. The sharing of passwords takes place outside the system. For a user to remember a password for each protected object is virtually impossible, and if the passwords are stored in programs they are vulnerable. To restrict access to certain access modes requires a password for each combination of access modes, but in most systems that use passwords, access to a protected object is all or none. In such implementations, revoking a user's access requires revoking access from all other users with similar access and then distributing a new password to those who are to retain access. This becomes almost Impossible when passwords are stored in programs. To be secure, passwords should be changed periodically, which is very difficult to do in such password protected DAC systems. In systems such as MVS the default access to a file is unrestricted access. A file is protected only when the password protection is initiated for that file. Thus a new file in MVS is not protected until the password protection mechanism is invoked.
If passwords are used as in the CDC NOS system to supplement another DAC mechanism, they do have one positive aspect. If all objects are protected with different passwords, Trojan horses can be restricted to only the objects that are handed to them. The use of passwords for a complete DAC is strongly discouraged, because there is no way to determine who has access to an object, and because managing such a system properly is very difficult.
Control permissions define which subjects have the ability to grant and revoke access permissions and change access modes. Sometimes control permissions include the ability to pass these control permissions to other subjects.
In contrast, access modes indicate a specific action that can be applied to he object. For example, the `execute' mode allows the object to be executed.
Two basic control permissions exist: control and control with passing ability. The difference between these permissions is the ability of the holder to propagate control to other subjects.
The advantage of a hierarchical structure is that control can be placed in the most trusted hands and the control can mimic the organizational environment. This should not imply, however, that control should be distributed based on one's position in the hierarchy. It is sometimes appropriate that a manager have no authorization for a subordinate's objects. The previously defined hierarchical structure provides the ability for multiple users to have the ability to control an object. Other hierarchical organizations can be imagined and implemented using control permissions. Hierarchical organizations could also be programmed into the DAC system without using control permissions, but such a restrictive implementation would result in a specific, fixed hierarchical structure. Such inflexible hierarchical control is not recommended. The hierarchical control model would satisfy the DAC requirement for all classes.
This near absolute control by owner can be implemented administratively. The system administrator could set up the system so that the default access would always contain control permission, but the ability to pass control permission to other users would never be used on the system. Of course, the system administrator has the ability to alter all of the access control on the system. Therefore, owner control can be viewed as a limited hierarchical system of only two levels and could be implemented with a flexible hierarchical control model.
Another way to implement owner control is by programming it into the DAC system and not implementing any control permissions. This will enforce the owner concept because the creator of an object is known to the DAC mechanism and can change the access, but has no method of passing control permission to another user. UNIX is an example of an operating system where only the owner of an object has the ability to change its access (protection bits).
A disadvantage of owner control is the difficulty it creates with regard to non-owner users changing their access modes for an object (i.e., it is harder to share the objects). In order to gain or lose any access to an object, users must ask the owner of the object to grant or revoke access for them. However, in some operating environments, this disadvantage is actually a desired system characteristic.
Owner control of objects eliminates confusion concerning who controls access to each object. This particular control model will meet the DAC requirement for all classes.
A pure owner control policy could be implemented without using the extended directory control. The subject who creates a file or a directory would receive the ability to control either. The hierarchical control scheme described above would use the extended directory control and the control permission with passing ability. Giving the system administrator, the department heads and the project leaders extended directory control to the appropriate directory in the storage structure would give them control over the appropriate portion of the file system. Laissez-faire could use the extended directory control, along with control permission with passing ability on both the directories and the files.
Depending on the situation, one of the above schemes or a combination of the above schemes could be used to implement the control model of the DAC mechanism for any evaluation class.
If access mode controls are placed only on files then controls are of a finer granularity. Access to individual files is controlled independently of other files under the same directory. But if no access controls are placed on directories, users could browse through the storage structure looking at the names of other users' files. Also, there is no control on where in the tree structure a subject could place a file, and this is usually the main purpose of a tree structure.
By having the access mode controls on both directories and files, a subject needs the correct access mode permissions to both the directory and the file before it is allowed to access the file.
Access modes for files are the basic software and hardware implemented access modes, such as those listed in Section 8.2, since the operating system has no knowledge of the semantics of the files. The rest of the objects (directories, mailboxes, etc.) are data structures maintained by the operating system, and their access modes are generally more elaborate extensions of the basic access modes and are usually implemented by protected subsystems.
In a system like UNIX, the lack of execute access implies no access to the existing entire sub-tree under that directory (ignoring an implementation of links as in UNIX and our earlier discussion of access permissions). A user cannot give another user access to a file without also giving the correct read access to the parent directories. In Multics, the philosophy chosen was to enable a user to grant access to a file just by setting the ACLs correctly on that file. Null access on a directory will prevent a user from seeing the names or ACLs of the children of that directory. But if the user has an access mode to a child, he can access the child (he must already know its name). This complicates decisions about when access should be given to the other attributes of a file (e.g., length, date contents modified). Such decisions depend on the particular implementation.
Write-append allows a user to add new objects to the directory (i.e., to create files and sub- directories under the directory). Null is implied if no access mode is specified.
In order to have more detailed access control, an implementor may add other access modes to the minimal set. But the final implementation of the access modes should not be so complicated that users cannot easily remember the implication of each mode. If users cannot distinguish the functions of each access mode, they will just grant to other subjects either the full access rights or no access rights to an object. Also, implementations of any access type must be consistent and guaranteed to always function correctly. In implementing any access type, the designer must consider how much complexity it adds to the trusted computing base, relative to the gain in functionality.
The reader should keep in mind that the implementations presented are not the only ones that will meet their respective requirement. The combinations possible with the mechanisms mentioned are too numerous to list here. Each implementation must be evaluated on an individual basis. The implementation selected should be as simple and user friendly as possible, while meeting the control objective. Since the mechanism is user-invoked, if it is overly complicated, users may avoid using it to its fullest extent.
At class C1 , users do not need special privileges to be authorized to control access to objects. Unprivileged users may control access to objects they can access. A user with access to an object can in turn grant access to that object to other users.
The class C1 DAC mechanism need only provide support to allow access/no access; separate modes for read and write need not be supported.
Objects may be shared by defined groups. That is, a group of users that may have access to an object must be defined to the TCB. Groups can be defined by naming the users to be included in each group.
This mechanism, called SEE-ONE, utilizes profiles, which contain a list of accessible objects for each subject. When a new object is created on this system, it is unprotected until the system administrator identifies it to the DAC mechanism. From that point on, a subject must have that object's name in his profile before he can access it. The system administrator must place the name of the object on the profiles of the subjects who should be allowed to access it. No access modes appear on the profiles. If an object is in a subject's profile, that subject has total access to that object (read, write, execute, delete). Subjects cannot pass access permissions on to other subjects. This particular mechanism does not support user groups.
While SEE-ONE will satisfy the C1 DAC requirement, it is not without drawbacks. Decentralizing control of protected objects from the system administrator to the user community may be desirable. Most systems have a considerable amount of object creation and deletion. Excessive object creation and deletion could overburden the system administrator. The implementation described here contains only the minimal functionality necessary to meet the C1 DAC requirement.
The mechanism must have the ability to include or exclude access to objects on a per user basis. If group access controls are provided, groups must be precisely defined by listing the unique names of the users in the group. Hence, groups are made of named users.
Users must possess special authorization to control access to objects. This special authorization is called control permission (see section 8.1). The authorization required may range from system administrator to users controlling access to objects that they have created. The latter is preferred because it does not require system administrator intervention. Either method is acceptable, but the former method could result in delays if the system administrator is not available.
When a creator requests the creation of an object, he must specify the desired access controls. Otherwise, the mechanism will enforce a restrictive default access control. The creator can grant other users the privilege of accessing the object as he wishes. Only the creator has the privilege of passing access on to other users. This concept is called ownership. Ownership is not transferrable to other users. If the creator wishes, he can specify a default protection list for all objects he creates. The default would contain a list of all users which will be added to the protection list of any new objects created by that subject.
This SEE-TWO implementation will satisfy the C2-B2 DAC requirement. Furthermore, it has an advantage over the SEE-ONE implementation; the management of an object is decentralized from the system administrator to the owner of that object. A disadvantage of the SEE-TWO implementation is that it does not provide the capability to grant access to groups of uniquely identified users. Using this mechanism could be cumbersome in some environments since all users must be explicitly listed. In other environments, however, requiring the users to be explicitly listed is desirable.
Additionally, for each object, authorized users must be able to specify a list of named users and a list of groups of named users that are not to be allowed to access that object. Thus, for example, an object could exist on a system that is public read-only except for JOE. USER who is not allowed to access the object at all.
When an object is created, an ACL that only permits access for the creator is associated with the object. All objects are protected. Each object's ACL describes the users or groups that can access it, along with their respective access modes to that object. Protected objects are segments and directories. The available access modes on segments are read, execute, and write. On directories the available access modes are search, modify, and append. A process must have modify access to the containing directory of an object in order to modify the ACL of the object.
Access groups are defined by the system projects, which are also used for accounting purposes. Only the system administrator can define projects by listing the unique identities of each user to be included in the projects. Users can be defined in more that one project, but can only be active in one project at a time. Changing projects requires that users logout of the system, and then login under the new project name.
If a user or group of users is listed on an object's ACL without an access mode, that individual or group has no access to that object. If a subject has more than one ACL entry on an object with conflicting access modes, the system takes the most restrictive access mode. This makes it possible to give everyone on a project access to an object, while denying certain members of that project any access at all. This can be done by including the project name on the ACL with the access mode desired while, at the same time, including those users to be excluded on the ACL with no access modes.
This BEE-THREE implementation will satisfy the B3-A1 DAC requirement. Furthermore, it has an advantage over the SEE-TWO implementation: it provides the capability to grant access to individual users or to groups of uniquely identified users. However, in this implementation it is impossible to allow a group some access to an object (such as read), but allow one group member some additional access (such as read, write) to that object.
By extending the access control mechanism to allow objects to be accessed in ways specified by subjects (programs as well as users), a system may allow a specific user-written program to be designated ``the only subject" allowed any access or a particular type of access to specific files. A protected subsystem can be defined as a collection of procedures and data objects that is encapsulated so that the internal structure of a data object is accessible only to the procedures of the protected subsystem, and the procedures may be called only at designated domain entry points and only by designated subjects.
The encapsulated data files are the protected objects. Programs in a protected subsystem act as managers for the protected objects and enforce user-written access controls on them. Subjects outside the protected subsystem are allowed to manipulate the protected objects only by invoking the manager programs. Any access constraints that can be specified in an algorithm can be implemented in a protected subsystem. Giving users the ability to construct protected subsystems out of their own program and data files allows users to provide more flexible controls on sharing.
By allowing programs inside a protected subsystem to invoke programs in another protected subsystem without compromising the security of either, multiple protected subsystems can be used to perform tasks. This limits the extent of damage a malicious or malfunctioning borrowed program might inflict on objects protected by the subsystem. Likewise, the lending user could also encapsulate the lent program in a protected subsystem of its own to protect it from the programs of the borrower.
The danger of Trojan horse attacks and the inadequacy of most DAC mechanisms to protect against such attacks was discussed in Section 6. A protected subsystem which incorporates one of the DAC mechanisms discussed earlier is no less vulnerable to attacks on objects within that subsystem. Furthermore, readers should consider the effects of illusory security which may be inherent with a protected subsystem.
Apollo's Domain [18] implements limited protected subsystems. Domain allows users to write their own subsystems, but it does not provide a mechanism for protected subsystems to interact with one another. A user has the ability to add a subsystem name to a system- wide list of subsystems, thereby creating the subsystem. The user then assigns a certain file to be a manager of the subsystem and another file to be an object. The user then removes all other access to the object, making the manager an exclusive accessor. Access to the subsystem is controlled by the access control lists associated with the subsystem manager.
The TFM must be easy to understand and follow, since proper set-up and proper administration of the DAC mechanism is critical to its effectiveness. In general, documentation should describe how to initialize the ACLs to best provide a protected environment. If the DAC mechanism is flexible and provides the ability to set up different control structures, examples should be given for a range of control structures and must indicate settings required for the product's evaluation class. The manual should explain Trojan horse attacks and should give an example of one that could defeat the DAC mechanism and be undiscovered by the audit mechanism.
The Security Features Users Guide (SFUG) must explain and give examples of how to use the DAC mechanism. The manual should be easy for the users to understand, since the mechanism is user-invoked. Like the manual for the system administrator, the users' manual should explain Trojan horse attacks and give an example of one that could defeat the DAC mechanism and be undiscovered by the audit mechanism.
At classes B3 through A1, access modes must be implemented, but they are highly recommended at all lower levels of the Criteria. The access modes read, execute, and write should be implemented at a minimum and write-append should be considered.
At class C2 and above, some sort of control permission must be implemented. The control models described in Section 8.1.1 are acceptable. The preferred model is the concept of ownership model. This model assures that some user is accountable for each object on the ADP system. Ownership should not be transferrable between users. If it is transferrable, ownership transfers must be audited.
Discretionary Access Control cannot deter hostile attempts to access sensitive information. DAC mechanisms can be designed to eliminate casual browsing through the storage system, to prevent accidental disclosure, modification, and destruction of data, and to provide for the sharing of data between users. A mandatory security policy must also be implemented to provide adequate protection if users are not allowed to share all data on the system. An effective audit trail mechanism is also necessary in order to detect hostile attacks on the DAC mechanism.
2. Schell, R. R., ``Security Kernels: A Methodical Design of System Security,'' in Technical Papers, USE Inc., Spring Conference, 5-9 March 1979, pp. 245-250.
3. Schroeder, M.D., Cooperation of Mutually Suspicious Subsystems, PhD dissertation, M.I.T., 1972.
4. Boebert, W.E., and Ferguson, C.T., ``A Partial Solution to the Discretionary Trojan Horse Problem,'' 9th Security Conference, DoD/NBS, September 1985, pp 141-144.
5. Downs, D, ``Discretionary Access Control Guideline,'' Aerospace Report, The Aerospace Corporation, September 1985.
6. Boebert, W.E., Kain, R.Y. and Young, W.D., ``Secure Computing: The Secure Ada Target Approach,'' Scientific Honeyweller, Vol. 6, No. 2 July 1985, pp 1-17.
7. Saltzer, Jerome H., ``Protection and the Control of Information in Multics,'' Communications of the ACM, Vol. 17, No. 7, July 1974, pp. 388-402.
8. Fabry, R.S., ``Capability-Based Addressing,'' Communications of the ACM, Vol. 17, No. 7, July 1974, pp. 403-411.
9. Redell, D.D., ``Naming and Protection in Extensible Operating Systems,'' AD-A001 721, published by M.I.T., Cambridge MA, November 1974.
10. Karger, P.A. and Herbert, A.J., ``Lattice Security and Traceability of Access,'' Symposium on Security and Privacy, IEEE, April 1984, pp. 13-23.
11. Gligor, V., Huskamp, J., Welke, S., Linn, C., and Mayfield, W., ``Traditional Capability-Based Systems: An Analysis of Their Ability to Meet the Trusted Computer Security Evaluation Criteria,'' IDA Paper Pl 935, October 1986.
12. Computer Associates, CA-SENTINEL Reference Guide, 1983.
13. Saltzer, Jerome H. and Schroeder, Michael D., ``The Protection of Information in Computer Systems,'' Proceedings of the IEEE, Vol. 63, No. 9, September 1975, pp. 1278- 1308.
14. Honeywell Informations Systems, Inc., Multics Programmer's Manual-Reference Guide, 7 ed., AG91.
15. UC Berkeley, UNIX Programmer's Manual, 7 ed., 1981.
16. IBM, Access Method Services, 1983.
17. Control Data Corporation, NOS Version 2 Reference Set, 3 ed., 1983.
18. APOLLO Computer Inc., The DOMAIN System Administrator's Guide, 3 ed., 1983.
19. Bell, D.E. and LaPadula, L.J., ``Secure Computer Systems: Unified Exposition and Multics Interpretation','' Tech. report MTR-2997 Rev. 1, MITRE Corp., March 1976.
20. Benzel Vickers, T., ``Overview of the SCOMP Architecture and Security Mechanisms,'' Tech. report MTR-9071, MITRE Corp., September 1983.