NCSC-TG-009
Library
No. S230,512
Version
1
FOREWORD
This
publication is issued by the National Computer Security Center
(NCSC)
as part of its program to promulgate technical computer security
guidelines. This interpretation extends the Department of
Defense Trusted
Computer System Evaluation Criteria (DOD 5200.28-STD) to
computer
security subsystems.
This document will be used for a period of at least one
year after date of
signature. During this period the NCSC will gain
experience using the
Computer Security Subsystem Interpretation in several
subsystem
evaluations. After this trial period, necessary changes
to the document will be
made and a revised version issued.
Anyone wishing more information, or wishing to provide
comments on the
usefulness or correctness of the Computer Security
Subsystem Interpretation
may contact: Chief Technical Guidelines Division,
National Computer
Security Center, Fort George G. Meade, MD 20755-6000,
ATTN: Cll.
~
PATRICK R GALLAGHER, JR. 16 September 1988
Director ~
National Computer Security Center
_
Computer Security Subsystems ACKNOWLEDGEMENT
ACKNOWLEDGEMENT
Acknowledgment is extended to the members of the working
group who produced
this Interpretation. Members were: Michael W. Hale,
National Computer
Security Center (Chair); James P. Anderson; Terry
Mayfie!d, Institute For
Defense Analyses; Alfred W. Arsenault, NCSC; William
Geer, NCSC; John C.
Inglis, NCSC; Dennis Steinauer, National Bureau of
Standards; Mario Tinto,
NCSC; Grant Wagner, NCSC; and Chris Wilcox, NCSC.
Acknowledgement is further extended to those individuals
who conducted
thorough reviews and and provided constructive comments
on this document.
Reviewers included: Steve Lipner, Earl Boebert, Virgil
Gligor, Debbie Downs,
Len Brown, Doug Hardie, Steve Covington, Jill Sole and
Bob Morris.
CONTENTS
1. INTRODUCTION..
........................................
1
1.1 PURPOSE
........................................ 1
1.2 BACKGROUND
.....................................
1
1.3 SCOPE
.......................................... 2
1.4 EVALUATION OF
SUBSYSTEMS.............. . . . . . . . . . . 3
1.4.1 Basis
for Evaluation . . . . . . . . . . . . . . 3
1.4.2 Integration
Requirements............. 5
1.4.3
WARNING..............................
7
2. FEATURE REQUIREMENTS
. . . . . . . . . . . . .
8
2.1 DISCRETIONARY
ACCESS CONTROL (DAC)
SUBSYSTEMS
........................................ 8
2.1.1 Global
Description of Subsystem Features . . . . 8
2.1.1.1 Purpose . . . . . . . . . . . . . .
. . . . 8
2.1.1.2 Role Within Complete Security
System . . . 8
2.1.2
Evaluation of DAC Subsystems . . . . . . . . . . 9
2.1.3 Feature
Requirements For DAC Subsystems. . . . . 9
2.1.3.1 DAC/Dl............................... 9
2.1.3.1.1 Identified users and objects. . . . 9
2.1.3.1.2 User-specified object sharing.
. . .. 10
2.1.3.1.3 Mediation ................... . 10
2.1.3.2 DAC/D2............................... 10
2.1.3.2.1 Single-user access granularity. . . .. 11
2.1.3.2.2 Authorized user-specified object
sharing
. . . . . . . . . . . . . . 11
2.1.3.2.3 Default protection....... 11
2.1.3.3 DAC/D3........................ 11
2.1.3.3.1 Access control lists for each
object ..........................
12
2.1.4
Assurance Requirements for DAC Subsystems. . . . 12
2.1.5
Documentation Requirements for DAC Subsystems. . 12
2.2 OBJECTREUSESUBSYSTEMS
........................... 14
2.2.1 Global Description of Subsystem
Features.. 14
2.2.1.1 Purpose....................... 14
2.1.2 Role Within the Complete Security
System 14
2.2.2 Evaluation
of Object Reuse Subsystems 14
2.2.3 Feature
Requirements for Object Reuse Subsystems 15
2.2.3.1 OR/D2
...................................... 15
iii
~
2.2.4 Assurance Requirements for Object Reuse
Subsystems........................................16
2.2.5 Docurnentation Requirements for Object
Reuse
Subsystems........................................16
2.3 IDENTIFICATION
& AUTHENTICATION (I&A)
SUBSYSTEMS
........... .......................................17
2.3.1 Global
Description of Subsystem Features . . . . . . . .17
2.3.1.1
Purpose
........................................17
2.3.1.2
Role Within Complete Security System . . . . . . 17
2.3.2 Evaluation of I&A Subsystems . . .
. . . . . . . . . 17
2.3.3 Feature
Requirements for I&A Subsystems . . .
.. . . 18
2.3.3.1
I&A/Dl ..........................................18
2.3.3.2
I&A/D2 ..........................................19
2.3.4 Assurance
Requirements for I&A Subsystems . . . . . . 20
2.3.5
Documentation Requirements for I&A Subsystems . . . . . 20
2.4
AUDITSUBSYSTEMS .............................................21
2.4.1 Global
Description of Subsystem Features . . . . . .
..21
2.4.1.1
Purpose .........................................21
2.4.1.2
Role Within Complete Security System ..
. . . . 21
2.4.2
Evaluation of Auditing Subsystems . . . . . .
.. . . 21
2.4.3 Feature
Requirements For Auditing Subsystems . .
.. . .22
2.4.3.1
AUD/D2 ....... ..................................22
2.4.3.1.1 Creation and management of audit
trail.. .................................22
2.4.3.1.2 Protection of audit data . .
. 23
2.4.3.1.3 Access control to audit .
. . 23
2.4.3.1.4 Specific types of events . .
. 23
2.4.3.1.5 Specific information per
event .
. 24
2.4.3.1.6 Ability to selectively audit
individuals............................. 24
2.4.3.2
AUD/D3 ............ ............................ 24
2.4.3.2.1 Real-timealarms
....................... 25
2.4.4
Assurance Requirements for Auditing Subsystems . . . . 25
2.4.5
Documentation Requirements for Auditing
Subsystenns .......................................... 25
3. ASSURANCE REQUIREMENTS
. . . . . . . . . . . . 26
3.1
SUBSYSTEMARCHITECTURE
.................................... 26
3.1.1 Arch:Dl
.......... ................................... 26
3.1.1.1
Execution Domain Protection . . . . . . . . .
26
3.1.1.2
Defined Subsets ............................... 27
3.1.2
Arch:D2
............................................. 27
-iv-
3.2 SUBSYSTEM INTEGRITY. . . . . . . . . . . . . . . . . . . . . 28
3.2.1
Integrity:Dl. . .
....................................28
3.2.2
Integrity:D2 . . . ....................................29
3.3 SECURITY
TESTING . . .
....................................29
3.3.1 Test:Dl
...............................................29
3.3.2 Test:D2
............................ ............
30
4. DOCUMENTATION REQUIREMENTS .......
............................31
4.1 SECURITY
FEATURES USER'S GUIDE . . . . . . . . .
. . 31
4.1.1 SFUG:Dl
...............................................31
4.1.2 SFUG:D2
...............................................31
4.2 TRUSTED
FACILITY MANUAL . . . . . . . . . . . .
. .
32
4.2.1 TFM:Dl
................................................32
4.2.2 TFM.D2
................................................32
4.3 TEST
DOCUMENTATION .........................................33
4.3.1 TD:Dl
.................................................33
4.3.2 TD:D2
.................................................33
4.4 DESIGN
DOCUMENTATION . . . . . . . . . . .
. .. 33
4.4.1 DD:Dl
.................................................33
4.4.2 DD:D2. .
. . .........
34
5. GLOSSARY . . . .
.............................................35
-v-
LIST OF TABLES
TABLE 1.1. Possible Subsystem Ratings . . . . . . . . . .
. . . . .4
TABLE 1.2. Required Supporting Functions . . . . . . . .
. . . . . 6
-vi-
Computer Security Subsystems INTRODUCTION
1. INTRODUCTION
This document provides interpretations of the Department
of Defense Trusted
Computer System Evaluation Criteria (DoD 5200.28-STD or
TCSEC) for computer
security subsystems.
A computer security subsystem (subsystem) is defined,
herein, as hardware, firmware and/or software which can
be added to a computer
system to enhance the security of the overall
system. A subsystem's primary
utility is to increase the security of a computer
system. The computer system
that the subsystem is to protect is referred to as the
protected system in
this Interpretation.
When incorporated into a system environment, evaluated
computer security
subsystems may be very effective in reducing or
eliminating certain types of
vulnerabilities whenever entire evaluated systems are
unavailable or
impractical.
1.1 PURPOSE
This Interpretation has been prepared for the following
purposes:
1. to establish a standard for manufacturers as to what
security features and
assurance levels to build into their new and planned
computer security
subsystem products to provide widely available products
that satisfy trust
requirements for sensitive applications;
2. to provide a metric to evaluate the degree of trust
that can be placed in a
subsystem for protecting classified and sensitive
information;
3. to lend
consistency to evaluations of these products by explicitly stating
the implications that are in the TCSEC; and
4. to provide the
security requirements for subsystems in acquisition
specifications.
1.2 BACKGROUND
The Department of Defense Trusted Computer System
Evaluation Criteria (DoD
5200.28-STD or TCSEC) was developed to establish uniform
DoD policy and
security requirements for "trusted, commercially
available, automatic data
processing (ADP) systems." Evaluation criteria
defined in the TCSEC provides a
standard to manufacturers as to what security features to
build into their
commercial products to satisfy trust requirements for
sensitive applications,
and serves as a metric with which to evaluate the degree
of trust that can be
placed in a computer system for the secure processing of
classified or other
sensitive information.
The TCSEC specifies a variety of features that a computer
system must provide
to constitute a complete security system. The security requirements specified
in the TCSEC depend on and complement one another to
provide the basis for
effective
1
Computer Security Subsystems INTRODUCTION
implementation of a security policy in a trusted computer
system. The
effectiveness of any one security feature present within
a system is,
therefore, dependent to some degree on the presence and
effectiveness of other
security features found within the same system. Because it was intended to be
used only for systems which incorporated all the security
features of a
particular evaluation class, the TCSEC does not, in all
cases, completely
specify these interdependencies among security features.
In addition to the class of trusted system products,
there exists a recognized
need for a class of computer security products which may
not individually meet
all of the security features and assurances of the
TCSEC. Instead, these
products may implement some subset of the features
enumerated in the TCSEC and
can potentially improve the security posture in existing
systems. These
products are collectively known as computer security
subsystems.
Evaluation of computer security subsystems against a
subset of the
requirements given in the TCSEC has proven an extremely
difficult task because
of the implied dependencies among the various features
discussed in the TCSEC.
As a consequence, interpretations of these
interdependencies and the relative
merits of specific subsystem implementations have been
highly subjective and
given to considerable variation.
This document provides interpretations of the TCSEC for
computer security
subsystems in an effort to lend consistency to
evaluations of these products by
explicitly stating the implications in the TCSEC.
Evaluations can be divided into two types: (l) a product
evaluation can be
perforrned on a subsystem from a perspective that
excludes the application
environment, or (2) a certification evaluation can be
done to assess whether
appropriate security measures have been taken to permit
an entire system to be
used operationally in a specific environment. The product evaluation type is
done by the National Computer Security Center (NCSC)
through the Trusted
Product Evaluation Process using this interpretation for
subsystems. The
certification type of evaluation lS done in support of a
formal accreditation
for a system to operate in a specific environment using
the TCSEC.
1.3 SCOPE
This document interprets the security feature, assurance
and documentation
requirements of the TCSEC for subsystem evaluations. In this interpretation,
the
2
Computer Security Subsystems INTRODUCTION
functional requirements of the TCSEC are divided into
four general categories:
1. Discretionary Access Control (DAC)
2. Object Reuse (OR).
3. Identification and Authentication (I&A)
4. Audit (AUD)
These categories form the basis for classifying products
to be evaluated as
computer security subsystems.
The document, in
addition to this introductory section, is organized into
three major sections and a glossary. Section 2 contains the feature
requirements for each of the above four categories on
which subsystems
evaluations are based.
The requirements in this section are listed in
increments, with only new or changed requirements being
added for each
subsequent class of the same feature. All requirements that are quoted from
the TCSEC are in bold print for easy identification and
are clarified, in the
context of subsystems, by interpretation paragraphs.
Section 3
contains the assurance requirements for all subsystems. The
assurances that are relevant to each category are listed
here in the same
format as the requirements in Section 2. Section 4 contains the requirements
and interpretations for subsystem documentation, again,
in the same forrnat as
Section 2.
The
TCSEC-related feature and assurance requirements described herein are
intended for the evaluation of computer security
subsystems designed to
protect sensitive information. This Interpretation, like the TCSEC, assumes
that physical, administrative, and procedural protection
measures adequate to
protect the inforrnation being handled are already in
place.
This
Interpretation can be used to support a certification evaluation. In
fact, it would be helpful whenever subsystems are a part
of the overall system
being certified.
1.4 EVALUATION OF SUBSYSTEMS
1.4.1 Basis for Evaluation
Subsystems are
evaluated for the specific security-relevant functions they
perforrn. This
Interpretation interprets the relevant TCSEC requirements for
each function evaluated.
So the function(s) for which subsystems are
evaluated will be identified within its ratings. Each function has its own
set of ratings as identified in Table 1.1. Subsystems that are evaluated for
more than one function will receive a separate
3
Computer Security Subsystems INTRODUCTION
rating for each function evaluated.
TABLE 1.1. Possible Subsystem Ratings
SUBSYSTEM
FUNCTION POSSIBLE
RATINGS
_ . _
Discretionary Access Control
DAC/D
DAC/Dl
DAC/D2
DAC/D3
Object
Reuse OR/D
OR/D2
Identification & Authentication
I&A/D
I&A/Dl
I&A/D2
Audit AUD/D
AUD/D2
AUD/D3
Although the
requirements for subsystems are derived from the TCSEC, the
ratings for subsystems will not directly reflect the
TCSEC class they are
derived from.
Since subsystems, by their very nature, do not meet all of the
requirements for a class Cl or higher computer system, it
is most appropriate
to associate subsystem ratings with the D division of the
TCSEC. This
Interpretation defines the Dl, D2 and D3 classes within
the D division for
subsystems. The Dl
class is assigned to subsystems that meet the
interpretations for requirements drawn from the Cl TCSEC
class. Likewise, the
D2 class consists of requirements and interpretations
that are drawn from the
C2 TCSEC class.
The D3 subsystem class is reserved for DAC subsystems and
audit subsystems that meet the B3 functionality
requirements for those
functions.
In addition to
meeting the functionality requirements and interpretations,
subsystems must also meet the assurance and documentation
requirements in
sections 3 and 4 of this document. The Dl and D2 classes have requirements
and interpretations for ~ssurances and documentation as
well as functionality.
The D3
4
Computer Security Subsystems INTRODUCTION
class contains additional requirements and
interpretations only for
functionality, not for assurances or documentation. So, subsystems with this
rating will adhere to the D2 assurance and documentation
requirements and
interpretations.
Like the classes
within the TCSEC, the Dl, D2 and D3 classes are ordered
hierarchically.
Subsystems being evaluated for the Dl class must meet the
requirements and interpretations for the Dl class. Subsystems being evaluated
for the D2 class must meet the requirements and
interpretations for the Dl
class plus the additional requirements and
interpretations for the D2 class.
Subsystems being evaluated for the D3 class must meet the
additional
requirements and interpretations associated with the
functionality at D3.
Although the
subsystem requirements and interpretations are derived
directly from the TCSEC, subsystems are not considered to
be complete computer
security solutions.
There is no general algorithm to derive a system rating
from an arbitrary collection of computer security
subsystems. Any collection
of individually evaluated subsystems must be evaluated as
a whole to determine
the rating of the resulting system. The ratings of the individual subsystems
in a complete system are not a factor in the rating of
that system.
1.4.2 Integration Requirements
Because all of
the TCSEC requirements for a given rating class were
intended to be implemented in a complete computer
security system, many of the
security features are dependent upon each other for
support within the system.
This poses a certain degree of difficulty with extracting
only the relevant
requirements from the TCSEC for a given feature. Further, this poses a
fundamental problem for subsystems because there is an
explicit dependency
between security features that restricts the "independent"
incorporation of
subsystems into the system's environment. The problem has been handled in
this Interpretation by discussing the integration
requirements for each type
of subsystem. The
requirements for integration are discussed for each type of
subsystem in a sub-section entitled, "Role Within
Complete Security System."
Furthermore, explicit requirements for integration are
stated in the
interpretations at appropriate points. The developer must show, and the
evaluation shall validate, that the subsystem can be
integrated into a system
to fulfill its designated role.
Most all
computer security subsystems will rely on other security-relevant
functions in the enviromnent where they are
implemented. Audit subsystems,
for example, depend on an identification and
authentication function to
provide the unique user identities that are necessary for
individual
accountability.
Also, it is important to realize that some of these functions
may be dependent on each other in a cyclic fashion (e.g.,
I&A depends on DAC
and DAC depends on I&A). In these
5
Computer Security Subsystems INTRODUCTION
cases, the cyclic dependencies should be removed either
by complete
integration of the functions or by modularizing the
functions in a way that
allows linear dependencies. Tl~is latter method is termed
"sandwiching" and
it requires the splitting of one function and surroundmg
the other dependent
function with the two functions resulting from the
split. For example, in the
case of DAC and I&A cyclic dependencies, one might
split I&A into two parts so
that there is a system I&A, a DAC subsystem, and a
DAC module containing its
own I&A functionality.
With the
exception of object reuse, all functions implemented by subsystems
will be dependent on other functions as shown in Table
1.2. The functions
upon which any subsystem is dependent will be referred to
as that subsystem's
required supporting functions. These required supporting functions must be
present in the subsystem's environment for the effective
integration of the
subsystem.
TABLE 1.2.
Required Supporting Functions
SUBSYSTEM
FUNCTION REQUIRED SUPPORTING
FUNCTIONS
~
Discretionary Access Control I&A
Audit
Object Reuse None
Identification & Authentication Audit
DAC2
Audit
I&A
DAC2
Subsystems that
are not self-sufficient in providing required supporting
functions must, at a minimum, provide an interface to
their required
supporting functions.
The
---------------------------------------------------
1 The audit supporting functions are required at D2.
2 Audit and/or authentication data must be protected
through domain isolation
or DAC.
6
Computer Security Subsystems INTRODUCTION
evaluation team will perform tests to show whether the
interface to the
required supporting functions is reliable and works
properly. The robustness
of the required supporting functions on the other side of
the interface will
not be tested, as the scope of the subsystem evaluation
is bounded by the
interface.
A more
integrated solution is for subsystems to be self- su~cient in
providing all of their required supporting
functions. Such subsystems w_ill
be evaluated and assigned a separate rating for each
function they provide.
Unlike the previous solution, where only an interface is
provided, each
required supporting function is performed by the
subsystem and must be a part
of the subsystem evaluation.
1.4.3 WARNING
An overan system
rating, such as that provided by the TCSEC, cannot be
inferred from the application of one or more
separately-rated subsystems.
Mechanisms, interfaces, and the extent of required
supporting functions for
each subsystem may differ substantiany and may introduce
significant
vulnerabilities that are not present in systems where
security features are
designed with fun knowledge of interfaces and host system
support. Therefore,
incorporation of an evaluated subsystem into any system
environment does not
automaticany confer any rating to the resulting
system.
7
Computer Security Subsystems FEATURE REQUIREMENTS
2. FEATURE REQUIREMENTS
2.1 DISCRETIONARY ACCESS CONTROL (DAC) SUBSYSTEMS
2.1.1 Global Description of Subsystem Features
2.1.1.1 Purpose
This subsystem
provides user-specified, controlled sharing of resources.
This control is established from security policies which
define, given
identified subjects and objects, the set of rules that
are used by the system
to determine whether a given subject is authorized to
gain access to a
specific object.
DAC features
include the means for restricting access to objects; the means
for instantiating authorizations for objects; and the
mechanisms for
distribution, review, and revocation of access privileges,
especially during
object creation and deletion.
2.1.1.2 Role Within Complete Security System
The requirement
is to give individual users the ability to restrict access
to objects created or controlled by them. Thus, given identified subjects and
objects, DAC includes the set of rules (group-oriented
and/or
individually-oriented) used by the subsystem to ensure
that only specified
users or groups of users may obtain access to data (e.g.,
based on a need-to-
know).
A DAC subsystem
controls access to resowces. As such, it
shall be
integrable with the operating system of the protected
system and shall mediate
all accesses to the protected resources. To fully protect itself and the
resources it controls, the DAC subsystem must be
interfaced to the protected
system in such a way that it is tamperproof and always
invoked.
DAC subsystems
use the identifiers of both subjects and DAC-controlled
objects as a basis for access control decisions. Thus, they must be supplied
with the identifiers in a reliable manner. The DAC subsystem may supply
subject identification for itself or it may rely on an
I&A mechanism in the
protected system or in another subsystem. It is also essential that DAC
subsystems be implemented in an environment where the
objects it protects are
well defined and uniquely identified.
At the DAC/D2
class, the DAC subsystem must interface with an auditing
mechanism. This
auditing mechanism can be included within the DAC subsystem,
or it may reside elsewhere in the subsystem's
environment.
8
Computer Security Subsystems FEATURE REQUIREMENTS
2.1.2 Evaluation of DAC Subsystems
Subsystems which
are designed to implement discretionary access controls to
assist a host in controlling the sharing of a collection
of objects must
comply with all of the TCSEC requirements as outlined
below for features,
assurances and documentation. Compliance with these requirements will
assure
that the subsystem can enforce a specifically defined
group-oriented and/or
individually-oriented discretionary access control
policy.
As a part of the
evaluation, the subsystem vendor shall set up the
subsystem in a typical functional configuration for
security testing. This
will show that the subsystem interfaces correctly with
the protected system to
meet all of the feature requirements in this section and
ali of the assurance
and documentation requirements in Sections 3 and 4. It will also show that
the subsystem can be integrated into a larger system
environment.
The
interpretations for applying the feature requirements to DAC subsystems
are explained in the subsequent interpretations
sections. The application of
the assurances requirements and documentation
requirements is explained in
Sections 3 and 4, respectively.
2.1.3 Feature Requirements For DAC Subsystems
2.1.3.1 DAC/Dl
- TCSEC Quote:
"Cl: New: 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., self/group/public controls, access
control lists) shall allow
users to special and control sharing of those objects by
named indinduals or
defined groups or both."
- Interpretation:
In the TCSEC quote, "TCB" is interpreted to
mean "DAC subsystem".
2.1.3.1.1 Identified users and objects ~.
DAC subsystems
must use some mechanism to determine whether users are
authorized for each access attempted. At DAC/Dl, this mechanism must control
access by groups of users. The mechanisms that can meet this requirement
include,
9
Computer Security Subsystems FEATURE REQUIREMENTS
but are not limited to: access control lists,
capabilities, descriptors, user
profiles, and protection bits. The DAC mechanism uses the identification of
subjects and objects to perform access control
decisions. This implies that
the DAC subsystem must interface with or provide some
I&A mechanism. The
evaluation shall show that user identities are available
to DAC.
2.1.3.1.2 User-specified object sharing
The DAC
subsystem must provide the capability for users to specify how
other users or groups may access the objects they
control. This requires that
the user have a means to specify the set of
authorizations (e.g., access
control list) of all users or groups permitted to access
an object and/or the
set of all objects accessible to a user or group (e.g.,
capabilities).
2.1.3.1.3 Mediation
The checking of
the specified authorizations of a user prior to granting
access to an object is the essential function of DAC
which must be provided.
Mediation either allows or disallows the access.
2.1.3.2 DAC/D2
- TCSEC Quote:
"C2: Change: The enforcement mechanism (e.g. self/group/public controls,
access control lists) shall allow users to specify and
control sharing of
those objects by named individuals, or defined groups of
individuals, or by
both, and shan provide controls to limit propagation of
access rights."
"C2: Add: The discretionary access control mechamsm
shan, either by explicit
user action or by default, provide that objects are
protected from
unauthorized access.
These access controls s~ll be capable of including or
excluding access to the granularity of a single wer. Access permission to an
object by users not already possessing access pernlission
shan only be
assigned by authorized users."
- Interpretation:
The following
interpretations, in addition to the interpretations for the
DAC/Dl Class, shall be satisfied at the DAC/D2
Class.
10
Computer Security Subsystems FEATURE REQUIREMENTS
2.1.3.2.1 Single-user access granularity
The DAC/D2 class
requires mdividual access controls; therefore, the
granularity of user identification must enable the
capabili~ to discern an
individual user.
That is, access control based upon group identi~ alone is
insufflcient. To
comply with the requirement, the DAC subsystem must either
provide unique user identities through its own I&A
mechanism or Mterface with
an I&A mechanism that provides unique user
identities. The DAC subsystem must
be able to interface to an auditing mechanism that
records data about access
mediation events.
The evaluation shall show that audit data is created and is
available to the auditing mechanism.
2.1.3.2.2 Authorized user-specined object sharing
The ability to
propagate access rights to objects must be lirnited to
authorized users.
This additional feature is incorporated to limit access
rights propagation.
This distribution of privileges encompasses granting,
reviewing, and revoking of acce