NCSC-TG-003

VERSION-1

NATIONAL COMPUTER SECURITY CENTER

A GUIDE TO

UNDERSTANDING

DISCRETIONARY

ACCESS CONTROL

TRUSTED SYSTEMS

30 September 1987

Approved for Public Release:

Distribution Unlimited.

NATIONAL COMPUTER SECURITY CENTER

FORT GEORGE G. MEADE, MARYLAND 20755-6000

NCSC-TG-003-87

Library No. S-228,576

FOREWORD

This publication, "A Guide to Understanding Discretionary Access Control In

Trusted Systems," is issued by the National Computer Security Center (NCSC)

under the authority of and in accordance with Department of Defense (DoD)

Directive 5215.1, "Computer Security Evaluation Center." The guidelines

defined in this document are intended to be used by computer hardware and

software designers who are building systems with the intent of meeting the

requirements of the Department of Defense Trusted Computer System Evaluation

Criteria, DoD 5200.28-STD.

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:

National Computer Security Center

9800 Savage Road

Fort George G. Meade, MD 20755-6000

Attention: Chief, Technical Guidelines Division

Patrick R. Gallagher, Jr. 30 September 1987

Director

National Computer Security Center

ACKNOWLEDGEMENTS

Special recognition and acknowledgement for their contributions to this

document are extended to the following:

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.

Contents

Page

FOREWORD................................................................... i

ACKNOWLEDGEMENTS.......................................................... ii

1. INTRODUCTION.............................................................1.

2. PURPOSE................................................................ 1

3. SCOPE.................................................................. 1

4. CONTROL................................................................ 2

5. DEFINITIONS............................................................ 3

6. AN INHERENT DEFICIENCY IN DISCRETIONARY ACCESS CONTROL................. 5

6.1 A FUNDAMENTAL FLAW IN DISCRETIONARY ACCESS CONTROL................ 5

6.2 AN EXAMPLE OF A TROJAN HORSE...................................... 5

7. AN OVERVIEW OF DAC MECHANISMS.......................................... 7

7.1 CAPABILITIES....................................................... 7

7.2 PROFILES.......................................................... 8

7.3 ACCESS CONTROL LISTS (ACLs)....................................... 9

7.3.1 WILD CARDS............................................... 9

7.3.2 DEFAULT ACLs............................................. 10

7.3.3 NAMED ACLs.............................................. 10

7.4 PROTECTION BITS................................................... 11

7.5 PASSWORD DAC MECHANISMS.......................................... 11

7.6 SUMMARY........................................................... 12

8. THE SET OF DAC ACCESS TYPES............................................ 13

8.1 CONTROL PERMISSIONS............................................... 13

8.1.1 CONTROL MODELS.......................................... 13

8.1.1.1 HIERARCHICAL..................................... 13

8.1.1.2 CONCEPT OF OWNERSHIP............................ 14

8.1.1.3 LAISSEZ-FAIRE.................................... 15

8.1.1.4 CENTRALIZED..................................... 15

8.1.2 FILE STRUCTURES AND CONTROL PERMISSIONS.................. 15

8.2 ACCESS MODES.................................................... 16

8.2.1 FILE STRUCTURES AND ACCESS MODES......................... 17

9. MEETING THE CRITERIA REQUIREMENTS.......................................19

iii

Page

9.1 THE C1 DAC REQUIREMENT............................................ 19

9.1.1 MINIMUM FUNCTIONALITY................................... 19

9.1.2 FUNCTIONALITY NOT REQUIRED.............................. 20

9.1.3 AN ACCEPTABLE IMPLEMENTATION............................ 20

9.2 THE C2 THROUGH B2 DAC REQUIREMENT................................ 20

9.2.1 MINIMUM FUNCTIONALITY..................................... 21

9.2.2 FUNCTIONALITY NOT REQUIRED............................... 21

9.2.3 AN ACCEPTABLE IMPLEMENTATION.............................. 22

9.3 THE B3 THROUGH A1 DAC REQUIREMENT................................ 22

9.3.1 MINIMUM FUNCTIONALITY..................................... 23

9.3.2 AN ACCEPTABLE IMPLEMENTATION............................. 23

10. OTHER TOPICS......................................................... 25

10.1 PROTECTED SUBSYSTEMS............................................. 25

10.2 ADMINISTERING AND USING DAC...................................... 25

10.3 AUDITING DAC..................................................... 26

10.4 VERIFYING DAC................................................... 26

10.5 DAC ADD-ONS...................................................... 27

11. SUMMARY OF DESIRED DAC FEATURES........................................28

12. REFERENCES.......................................................... 29

1. INTRODUCTION

The main goal of the National Computer Security Center is to encourage the

widespread availability of trusted computer systems. In support of that goal

a metric was created, the Department of Defense Trusted Computer System

Evaluation Criteria (the Criteria) Il], against which computer systems could

be evaluated for security.

2. PURPOSE

One of the features of the Criteria that is required of a secure system is the

enforcement of discretionary access control (DAC). DAC is a means of

restricting access to objects based on the identity of subjects and/or groups

to which they belong. The controls are discretionary in the sense that a user

or process given discretionary access to information is capable of passing

that information along to another subject. This guide discusses issues

involved in designing, implementing and evaluating DAC mechanisms. Its

primary purpose is to provide guidance to manufacturers on how to select and

build effective DAC mechanisms. Any examples of DAC mechanisms in this

document are not to be construed as the only implementations that will satisfy

the Criteria requirement. The examples are merely suggestions of appropriate

implementations. The Criteria is the only metric against which systems are to

be evaluated. In addition to showing examples of DAC mechanisms, this guide

will restate and elaborate on the Criteria requirements for DAC. This guide

is part of an on-going program to augment the Criteria on the issues and

features it addresses.

3. SCOPE

The guidelines and interpretations established in this document apply to the

discretionary access control requirements as expressed in the Criteria. The

recommendations apply to computer systems and products that are being built or

modified with the intention of meeting the requirements of the Criteria.

4. CONTROL OBJECTIVES

The term ``control objective'' refers to a statement of intent with respect to

control over some aspect of an organization's resources or processes. In

terms of a computer system, control objectives provide a framework for

developing a strategy for fulfilling a set of security requirements. In

particular, a given system can only be said to be secure with respect to its

enforcement of some specific policy [2]. The control objective for security

policy is as follows:

"The security policy is a statement of intent with regard to control over

access to, dissemination of, and modification of information. The

security policy must be precisely defined and implemented for each system

that is used to process sensitive information. The security policy must

accurately reflect the laws, regulations, and general policies from which

it is derived.''

Discretionary control is the most common type of access control mechanism

implemented in computer systems today. The basis of this kind of security is

that an individual user, or program operating on the user's behalf, is allowed

to specify explicitly the types of access other users (or programs executing

on their behalf) may have to information under the user's control.

Discretionary security differs from mandatory security in that it implements

the access control decisions of the user. Mandatory controls are driven by

the results of a comparison between the user's trust level or clearance and

the sensitivity designation of the information.

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:

Security policies defined for systems that are used to process classified

or other sensitive information must include provisions for the enforcement

of discretionary access control rules. That is, they must include a

consistent set of rules for controlling and limiting access based on

identified users who have been determined to have need-to-know for the

information.

5. DEFINITIONS

Discretionary Access Control (DAC)-The Criteria defines discretionary access

control as:

``A means of restricting access to objects based on the identity of

`subjects and/or groups to which they belong. The controls are

`discretionary in the sense that a subject with a certain access

`permission is capable of passing that permission (perhaps indirectly) on

`to any other subject."

DAC controls are used to restrict a user's access to protected objects on the

system. The user may also be restricted to a subset of the possible access

types available for those protected objects. Access types are the operations

a user may perform on a particular object (e.g., read, write, execute).

Typically, for each object, a particular user or set of users has the

authority to distribute and revoke access to that object. Users may grant or

rescind access to the objects they control based on "need to know" or "whom do

I' like" or other rules. DAC mechanisms control access based entirely on the

identities of users and objects.

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, 1/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.

6. AN INHERENT DEFICIENCY IN DISCRETIONARY ACCESS CONTROL

6.1 A FUNDAMENTAL FLAW IN DISCRETIONARY ACCESS CONTROL

Discretionary access control mechanisms restrict access to objects based

solely on the identity of subjects who are trying to access them. This basic

principle of discretionary access control contains a fundamental flaw that

makes it vulnerable to Trojan horses [3], [4]. On most systems, any program

which runs on behalf of a user inherits the DAC access rights of that user

[5]. An example of the workings of a Trojan horse will illustrate how most

DAC mechanisms are vulnerable. Reference [6] contains such an example, which

is similar to the following:

6.2 AN EXAMPLE OF A TROJAN HORSE

Consider a system where an access control list mechanism (as described in

Section 7.3) is used to implement discretionary access control. There are two

users on this particular system: an honest user, DOE; and a dishonest user,

DRAKE. DOE has a data file which contains highly sensitive data; this file is

known as DOESFILE. He has diligently set the ACL to allow only himself to

read the file. No other users are authorized to access the file. DOE is

confident that no one but himself will be able to access his data file.

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.

7. AN OVERVIEW OF DAC MECHANISMS

This section presents an overview of the most commonly used DAC mechanisms.

Each mechanism will be described briefly. Section 9 explains how each of

these mechanisms rates against the Criteria.

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:

1 Capabilities

2. Profiles

3. Access Control Lists (ACLs)

4. Protection Bits

5. Passwords

ACCESS CONTROL MATRIX

Objects KIMSFILE DONSFILE PAYROL1 PAYROL2 DOESFILE

Users:

Kim rw r rw r

Joe r

Don rw r

Jones r

Doe rw

Mgr Jim cp cp c c c

Jan rw rw

Figure 1

The access control matrix such as the example in figure 1- above, is a

pictorial view of a set of users and their access permissions to a set of

protected objects. The access type ``r'' denotes read access and the access

type ``w'' denotes write access. The access type ``c'' means control

permission and the access type ``cp'' means control with passing ability. The

access types are explained in Section 8.

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.

7.1 CAPABILITIES

In a capability-based system, access to protected objects such as files is

granted if the would- be accessor possesses a capability for the object. The

capability is a protected identifier that both identifies the object and

specifies the access rights to be allowed to the accessor who possesses the

capability. Two fundamental properties of capabilities are that they may be

passed from one accessor (subject) to another, and that the accessor who

possesses capabilities may not alter or fabricate capabilities without the

mediation of the operating system TCB.

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, chang