GUIDE TO UNDERSTANDING TRUSTED FACILITY
MANAGEMENT
June
1989
NATIONAL COMPUTER SECURITY CENTER
NCSC-TG-O15
Library No. S-231,
429
FOREWORD
The National Computer Security Center (NCSC) has
established an aggresive
program to study and implement computer security
technology and to
encourage the widespread availability to trusted computer
operations. To
provide insight into the Trusted Computer Systems
Evaluation Criteria
(TCSEC) and to assure that each feature of the TCSEC will
be discussed in
detail and provide the proper interpretation with
specific guidance, the
NCSC has established a Technical Guideline Program This Technical
Guideline Program, and the cooperative business
relationship being forged
with the computer and telecommunication industries, will
result in the
fulfillment of our country's computer security
requirement. We are
determined to meet the challenge of identifying trusted
computer
guidelines suitable for use in processing all types and
classifications of
information.
"A Guide to Understanding Trusted Facility
Management" is the latest in
the series of technical guidelines that are being
published by the
National Computer Security Center. This technical guideline has been
written to help the computer security manufacturers,
system evaluators,
accreditors, as well as end users understand what
procedures, methods, and
processes are required for trusted facility management at
B2 through A1
classes ofthe TCSEC.
As the Director, National Computer Security Center, I
invite your
recommendations for revision to this technical
guideline. We plan to
review this document periodically or when the need
arises.
_______________
Patrick R. Gallagher Jr. 15
August 1989
Director
National Computer Security Center
ACKNOWLEDGMENTS
Special recognition for their contributions to this
document are extended
to Info Systems Technology, Inc., and to Dr. Virgil D.
Gligor of the
University of Maryland as primary author of this
document, and to Ms.
Valerie A. Maurer and MAJ James P. Gordon (U S Army) as
Project Managers
for the production and preparation of this guideline.
Acknowledgment is given to the many computer vendor
representatives, and
members of the National Computer Security Center (NCSC)
community, who
enthusiastically gave of their time and technical
expertise in reviewing
the guideline and providing valuable comments and
suggestions. Special
thanks is given to Ms. Carol Lane, Mr. Leon Howell and
Mr. Douglas Hardie
for their invaluable assistance and guidance in this
effort.
PREFACE
This guideline contains information derived from the
requirements of the
TCSEC prefaced by the word "shall", and
recommendations derived from good
practices prefaced by the word "should" when
conducting trusted facility
management. The
recommendations in this document are also not to be
construed as supplementary requirements to the
TCSEC. The TCSEC is the
only metric against which systems are to be evaluated.
Throughout this guideline there will be examples,
illustrations, or
citations of administrative roles and operations that
have been used in
trusted facility management. The use of these examples, illustrations,
and citations does not mean that they contain the only
acceptable
procedures, methods, or processes. The selection of these examples is
based solely on their availability in the computer
security literature.
Examples in this document are not to be construed as the
only
implementations that will satisfy the TCSEC requirements
or intended to
single out any particular operating system to highlight
weaknesses and
shortfalls, but merely to provide clarification. The examples are
suggestions of appropriate implementations.
TABLE OF
CONTENTS
FOREWORD i
ACKNOWLEDGMENTS ii
PREFACE iii
1. INTRODUCTION 1
1.1. PURPOSE 1
1.2. SCOPE 2
1.3. CONTROL OBJECTIVES 3
2. SECURITY
ADMINISTRATION - THE PROBLEM 4
3. TCSEC
REQUIREMENTS FOR TRUSTED FACILITY MANAGEMENT 5
3.1. REQUIREMENTS FOR SECURITY CLASS B2 5
3.1.1. Security Policy 5
3.1.2. Accountability 5
3.1.3. Operational Assurance 5
3.1.3.1. System Architecture 5
3.1.3.2. Trusted Facility Management 6
3.1.4. Life-Cycle Assurance 6
3.1.4.1. Security Testing 6
3.1.4.2. Design Specification and Verification
6
3.1.4.3. Configuration Management 7
3.1.5. Documentation 7
3.1.5.1. Trusted Facility Manual 7
3.1.5.2. Test Documentation 8
3.1.5.3. Design Documentation 8
3.2. REQUIREMENTS FOR SECURITY CLASS B3 9
3.2.1. Security Policy 9
3.2.2. Accountability 9
3.2.3.
Operational Assurance 9
3.2.3.1. System Architecture 9
3.2.3.2. Trusted Facility Management 9
3.2.3.3. Trusted Recovery 11
3.2.4. Life-Cycle Assurance 11
3.2.4.1. Security Testing 11
3.2.4.2. Design Specification and Verification
11
3.2.4.3. Configuration Management 11
3.2.5. Documentation 11
3.2.5.1. Trusted Facility Manual 11
3.2.5.2. Test Documentation 11
3.2.5.3. Design Documentation 11
3.3. REQUIREMENTS OF SECURITY CLASS A1 12
3.3.1. Additional Life-Cycle Assurance Requirements
12
3.3.1.1. Configuration Management 12
3.3.1.2. Trusted Distribution 12
4. SATISFYING THE
TCSEC REQUIREMENTS 13
4.1. SEPARATION OF ADMINISTRATOR AND OPERATOR 13
4.1.1. Security-Relevant Functions of the System
Administrator
16
4.1.2. Security-Relevant Functions of the Operator
17
4.2. SEPARATION OF SECURITY AND
NONSECURITY-RELEVANT FUNCTIONS 17
4.3. IMPACT OF OTHER TCSEC REQUIREMENTS 19
5. SEPARATION OF
OPERATOR'S AND ADMINISTRATOR'S ROLES 21
5.1. FUNCTIONS OF THE SECURITY ADMINISTRATOR 24
5.2. FUNCTIONS OF THE SECURE OPERATOR 30
5.3. FUNCTIONS OF THE ACCOUNT ADMINISTRATOR 31
5.4. FUNCTIONS OF THE AUDITOR 32
5.5. FUNCTIONS OF THE OPERATOR 36
5.6. FUNCTIONS OF THE SYSTEM PROGRAMMER 37
5.7. OTHER ROLES 38
5.8. RELATIONSHIP AMONG ADMINISTRATIVE ROLES 39
6. IMPACT OF OTHER TCSEC REQUIREMENTS 42
6.1. SECURITY POLICY 42
6.2. ACCOUNTABILITY 43
6.3. ASSURANCE 44
6.3.1. Operational Assurance 44
6.3.2. Life-Cycle Assurance 46
6.4. DOCUMENTATION 46
GLOSSARY 47
REFERENCES 58
LIST OF FIGURES
Figure 1. Required Class B2 Separation of Functions,
Privileges,and
Databases 16
Figure 2. Required Class B2 and Class B3 Separation
of Functions, Privileges, and Databases of
Administrative Roles 19
Figure 3. Recommended Separation of Functions,
Privileges, and
Databases of Administrative Roles 23
Figure 4. Relationships Among Administrative Roles 41
1. INTRODUCTION
The principal 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 DoD
Trusted Computer System
Evaluation Criteria (TCSEC), against which computer
systems could be
evaluated for security.
The TCSEC was originally published on 15 August
1983 as CSC-STD-001-83.
In December 1985 the DoD adopted
it, with a few
changes, as a DoD Standard, DoD 5200.28-STD. DoD Directive 5200.28,
"Security Requirements for Automated Information Systems (AISs)",
has
been written, among other reasons, to require the
Depart*ment of Defense
Trusted Computer System Evaluation Criteria be used
throughout the DoD.
The TCSEC is the standard used for evaluating the
effectiveness of
security controls built into AISs. The TCSEC is divided into four
divisions: D, C,
B, and A, ordered in a hierarchical manner with the
highest division (A) being reserved for systems providing
the best
available level of assurance. Within divisions C , B, and A, there are
subdivisions known as classes, which are also ordered in
a hierarchical
manner to represent different levels of security.
1.1.
PURPOSE
An important
assurance requirement of the TCSEC, which appears in
all classes from B2 to A1, is trusted facility
management. This refers to
the administrative procedures, roles, functions (e.g.,
commands, programs,
interfaces), privileges and databases that are used for
secure system
configuration, administration and operation.
The objective
of trusted facility management is to support
security and accountability policies throughout a
system's operation. To
accomplish this goal, two key requirements are the
separation between
Administrator and Operator functions, in class B2, and
between
security-relevant and nonsecurity-relevant functions of
System
Administrators, in class B3. This separation of administrative and
operator functions, and security-relevant and
nonsecurity-relevant
functions of System Administrators, also applies to class
A1. These
separations help ensure that security-adverse effects of
human error,
misdeed, and system failure do not affect administrative
functions and
data.
The purpose of
"A Guide to Understanding Trusted Facility
Management" is to provide guidance to manufacturers
on how to incorporate
functions of trusted facility management into their
systems; to system
evaluators and accreditors on how to evaluate the design
and
implementation of trusted facility management functions;
and to end users
on how to use these functions effectively, e.g., on how
to avoid common
pitfalls of system management.
1.2.
SCOPE
The guidelines
for trusted facility management presented herein
refer to the separation of administrative functions,
interfaces, and
procedures of an important assurance requirement of classes
B2 through A1
of the TCSEC. This
guideline is intended to present the issues involved
in the design of trusted facility management.
This guideline
contains five.additional sections.
Section 2
contains a brief overview of the inherent vulnerabilities
of
administrative roles.
Section 3 presents TCSEC requirements that affect
the design and implementation of trusted facility
management functions,
and includes recommendations corresponding to each
evaluation class.
Section 4 reviews the major requirements of trusted
facility management as
stated in the TCSEC.
Section 5 presents the separation between
Administrator's and Operator's functions and the possible
partitioning of
the security-relevant functions of the Administrator and
Operator into
separate roles, functions and databases. Section 6 discusses the impact
of the other TCSEC requirements on trusted facility
management, including
design and modeling alternatives for trusted facility
management.
Not addressed
herein are personnel security measures, physical
security of the automated information system equipment, and other
administrative measures external to the AIS. The evaluation of these
measures is beyond the scope of TCSEC-based evaluations
[12, p.87]. These
guidelines apply to computer systems, processing
environments, and
products built or modified with the intention of
satisfying the TCSEC
requirements. Note
that this document contains suggestions and
recommendations derived from TCSEC objectives but which
are not required
by the TCSEC.
Additional recommendations are made, which are derived from
the stated objectives of the TCSEC.
1.3.
CONTROL OBJECTIVES
Trusted
facility management is one of the areas of operational
assurance. As
such, the trusted facility management is an aspect of the
objective, "assurance." The assurance objective provided in the TCSEC
is:
"Systems
that are used to process classified or other
sensitive information must be designed to guarantee
correct and accurate
interpretation of the security policy and must not
distort the intent of
that policy.
Assurance must be provided that correct implementation and
operation of the policy exists throughout the system's
life cycle."
This objective
affects trusted facility management in two
important ways.
First, administrative roles of the system are the key
components that help to ensure the enforcement of the
system security
policy, and thus, their function must support the intent of
that policy.
Second, the administrative roles must satisfy the
life-cycle assurance
requirements of correct implementation and operation.
2. SECURITY ADMINISTRATION - THE PROBLEM
Weaknesses of trusted facility management are role
specific and common to
all administrative roles.
Careful examination of both common
administrative roles and role-specific weaknesses is
important for both
system designers and administrators because exposure to
some of these
weaknesses can be reduced or eliminated by specific
designs or by
administrative procedure external to the system in
use. The distinction
between the two types of weaknesses is also useful for
the strengthening
of mechanisms and procedures supporting different roles
selectively.
The weaknesses discussed below are generic in the sense
that they are not
specific to any particular system or design. Careful analysis should be
performed in designing and implementing specific systems
to identify
specific additional weaknesses and their required
countermeasures.
Design, implementation, and use of auto*mated tools for
analyzing specific
system weaknesses are useful, but still a research
subject [1].
Three types of weaknesses affect all administrative roles
to various
degrees:
(1)
unauthorized modification of hardware and software
system configuration Unauthorized changes of system
configuration, including
both hardware and software changes, can take place during
all phases of a
system life-cycle.
(2) penetration of a specific administrative
role.
Penetration of administrative roles by non-administrative
users, or by
unauthorized administrative users, is usually made
possible by flawed, or
weak, mechanisms for identification and authentication,
TCB protection, or
role separation.
(3) misuse of administrative authority. This can
arise from careless or deliberate misuse of
administrative authority.
Misuse of authority can cause both TCB and user security
violations, and
therefore can lead to extensive damage.
3. TCSEC REQUIREMENTS FOR TRUSTED FACILITY
MANAGEMENT
In the TCSEC, n requirements for Trusted Facility
Management are for
security classes B2 through A1. Classes C1 through B1 have no Trusted
Facility Management requirements.
3.1.
REQUIREMENTS FOR SECURITY CLASS B2
3.1.1.
Security Policy
No
Additional Requirements.
3.1.2.
Accountability
All
identification and authentication requirements of
class B2, including trusted path, shall apply to the
administrative users
individually.
All
actions of administrative users shall be auditable in
accordance with the B2 audit requirements.
3.1.3.
Operational Assurance
3.1.3.1.
System Architecture
The
TCB programs and data structures
implementing administrative functions:
*
must satisfy the modularity requirements of
class B2;
*
must satisfy the least privilege principle;
*
must use logically distinct storage objects
with separate attributes (e.g., files, segments).
The
interfaces of the administrative roles
implemented by the TCB must be completely defined, and
all the elements of
the TCB implementing the administrative roles must be
identified.
3.1.3.2.
Trusted Facility Management
The
TCB shall support separate Operator and
Administrator functions.
The Administrator's functions include those of:
*
the Security Administrator
*
System Programmer
*
the Auditor
*
the Account Administrator
(whenever this role is defined to be security-relevant).
These functions must be separated from those of the
Secure Operator.
While the Administrator's functions may be combined into
one function, we
recommend they be separated as described in section
5. The remaining
functions include only the nonsecurity-relevant
functions.
3.1.4.
Life-Cycle Assurance
3.1.4.1.
Security Testing
All
security testing requirements of class B2
apply to the TCB functions and interfaces implementing
administrative
roles as stated.
3.1.4.2.
Design Specification and
Verification
Recommendation:
-Descriptive
Top-Level
Specifications (DTLSs) of the TCB functions and
interfaces implementing
administrative roles must be maintained that completely
and accurately
describe these functions and interfaces in terms of
exceptions, error
messages, and effects.
-A
formal security and
integrity model of trusted facility management should be
used to define the
separation of administrative roles, functions, privileges
and databases.
3.1.4.3.
Configura*tion Manage*ment
All
configuration management requirements of
class B2 apply to the TCB functions and interfaces implementing
administrative
roles as stated.
3.1.5.
Documentation
3.1.5.1.
Trusted Facility Manual
A
manual shall be available that provides the
following:
*
be addressed to the ADP
system administrator shall present cautions about
functions and privileges
that should be controlled when running a secure facility.
*
give procedures examining
and maintaining the audit files.
*
give the detailed audit
record structure for each type of audit event.
* describe the operator
and
administrator functions related to security, to include
changing the security
characteristics of a user.
*
provide guidelines on the
consistent and effective use of the protection features
of the system.
*
explain how the protection
features of the system interact.
*
show how to securely
generate a new TCB.
*
provide guidelines on
facility procedures, warinings, and privileges that need
to be controlled in
order to operate the facility in a secure manner.
*
identify the TCB modules
that contain the reference validation mechanism.
*
describe the procedures
for secure generation of a new TCB from source after
modification of any
modules in the TCB.
3.1.5.2.
Test Documentation
All
test documentation requirements of class B2,
except those for covert channel testing, apply to the TCB
functions and
interfaces implementing administrative roles as stated.
3.1.5.3.
Design Docu*menta*tion
Documentation
shall be available that provides a
description of:
* Interfaces between the TCB modules
implementing functions of the administrative roles;
*
Specific TCB protection mechanisms used for
the separation of administrative roles;
* Descriptions of the TCB modules
implementing functions and interfaces of the
administrative roles;
* How the least privilege principle is
supported by the functions and interfaces of the TCB
implementing
administrative roles;
* How
the actions of the administrative
roles are audited.
Recommendation:
-A formal
description of the security and integrity policy model
used to define the separation of administrative roles
should be available
and proven to be sufficient to enforce the claimed
separation.
3.2.
REQUIREMENTS FOR SECURITY CLASS B3
All the
requirements of Class B2 are included at this level. The
additional class B3 requirements are listed below.
3.2.1.
Security Policy
No Additional
Requirements.
3.2.2.
Accountability
The
trusted-path requirements of class B3 apply to
administrative users.
The
additional audit requirements of class B3 apply to the
administrative users.
3.2.3.
Operational Assurance
3.2.3.1.
System Architecture
The
additional TCB structuring requirements of
class B3 (i.e., significant use of abstraction,
information hiding, and
layering) apply to the functions and interfaces of the
TCB implementing
administrative roles.
3.2.3.2.
Trusted Facility Management
The
security-relevant administrative functions
(i.e., those of the Security Administrator, System
Programmer, Auditor and
the Secure Operator's roles defined above) must be
separated from the
nonsecurity-relevant administrative functions.
The
security-relevant administrative functions
must be limited to those that are essential to performing
the security
roles effectively.
All
actions of security personnel (Secure
Administrator and Secure Operator) must be audited.
Recommendations:
-
The functions of security administration and
personnel should distinguish among
*
System
Programmer, Security Administrator, Auditor, and Secure
Operator
*
their privileges
*
their databases.
-
Different levels of trust should be
established for the following roles in accordance with
the power and
vulnerability of each role:
*
System Programmer (maintenance and
diagnostics mode);
* Security Administrator;
* Auditor;
* Secure Operator;
* Account Administrator;
* Operator.
(Note:
The distinction between the System
Administrators, Operators, and System Security Officers
is explicitly made
in the audit requirements of the TCSEC [11, p. 16]. These roles
correspond to the Account Administrator, Secure/Normal
Operator, and
Security Administrator/Auditor roles above. Also note that these
distinctions do not require the separation of
security-relevant and
nonsecurity-relevant functions as they are made in the
audit -- not
trusted facility management -- requirement area).
3.2.3.3.
Trusted Recovery
The
trusted recovery requirement of class B3
applies to the functions and interfaces of the TCB
implementing
administrative roles.
3.2.4.
Life-Cycle Assurance
3.2.4.1.
Security Testing
All
additional security testing requirements of
class B3 apply to the functions and interfaces of the TCB
implementing
administrative roles.
3.2.4.2.
Design Specification and
Verification
Recommendation:
-
The additional design
specification and verification requirements of class B3
should be applied to
the functions and interfaces of the TCB implementing
administrative roles.
3.2.4.3.
Configuration Management
No
Additional Requirements.
3.2.5.
Documentation
3.2.5.1.
Trusted Facility Manual
The
additional requirements shall include
procedures to ensure that the system is initially started
in a secure
state and procedures to resume secure system operation
after any lapse in
system operation.
3.2.5.2.
Test Documentation
No
Additional Requirements.
3.2.5.3.
Design Docu*menta*tion
No
Additional Requirements.
3.3.
REQUIREMENTS OF SECURITY CLASS A1
All
requirements of the security class B3 are included here. The
only additional requirements are in the following
"Life-Cycle Assurance"
areas:
3.3.1.
Additional Life-Cycle Assurance Requirements
3.3.1.1.
Configuration Management
All
additional configuration management
requirements of class A1 apply to the TCB functions and
interfaces
implementing administrative roles.
3.3.1.2.
Trusted Distribu*tion
All
trusted distribution requirements of class
A1 apply to the TCB functions and interfaces implementing
administrative
roles.
4. SATISFYING THE TCSEC REQUIREMENTS
The principal
requirements of trusted facility management are:
*
the separation of Operator and Administrator
functions;
*
the logical (or physical) separation of the
database information corresponding to those functions;
and
*
the implementation of least privilege such
that functions have only the minimum necessary privileges
to the databases.
4.1.
SEPARATION OF ADMINISTRATOR AND OPERATOR FUNCTIONS
The separation
of Administrator and Operator functions is a
requirement of TCSEC class B2, which states:
"The
TCB shall support separate Operator and Administrator
functions."
The primary
purpose behind the separation of the Operator and
Administrator functions is to limit the potential damage
that untrusted,
or errant, code can inflict on the information the TCB
uses to enforce the
security policy.
Any code executed with Operator or Administrator
privileges has the ability to change the TCB data
structures, thus
affecting the enforcement of policy. Through the application of the
principal of least privilege and the separation of
Operator and
Administrator functions so that they are prevented from
executing
untrusted code, the TCB data structures can be
protected. The principle
of least privilege requires that each subject be granted
the most
restrictive set of privileges needed for the specific
task. In the case
of the operator and administrator functions, the
privileges need to be
established at a low level of granularity so that the
proceses that
implement those functions do not have unnecessary
privileges. This low
level of granularity provides several important
protections:
*
limits the effects of errors on the part of
the administrator;
*
limits the effects of incorrect code which
implements the administrator functions;
*
provides some protection against malicious
administrators, in that damage that can be done is
strictly contained to the
provileges defined for that role. Some additional protection is afforded by
the auditing of administrator actions. (This argument can be extended to
malicious code which is inserted in the administrator
functions.)
The TCSEC
recognizes the need to separate the operator and
adminstrator functions from the normal user abilities to
execute code.
There are several ways to implement such separation. One way is to
enforce those restrictions on the Administrator and
Operator functions.
They can only execute trusted code that has been shown to
preserve the TCB
data structures properly.
This requires that the people who perform those
functions also have a separate account that allows them
to be a normal
user. That
separate account would not have any Operator or Administrator
capabilities.
Whatever approach to separation is selected, it must be
shown to restrict the Operator or Administrators from
executing untrusted
code.
The separation
of Operator and Administrator functions, namely
between the commands, programs, and interfaces
implementing those
functions, is important because these functions are used
with different
privileges, on different system data. Should these functions not be
separated, Operators could use commands that include
Administrators'
privileges and databases.
This would mean that all Operators would need
to be trusted to the same degree as that needed for
Administrators. It
would also mean that the principles of least privilege
and separa*tion of
privilege, which are two of the most important security
principles (see
reference [18] for a further explanation of these
principles), are
violated, overexposing the system to error, failure, and
misdeed.
Furthermore, lack of functional separation would fail to
confine the
effects of any function penetration, leaving the entire
system in a
vulnerable state.
In addition to
the separation of Administrator and Operator
functions, trusted facility management should also
separate internal
system databases which the Operator and Administrator
manipulate. Checks
and balances are necessary to avoid trusting too many
all-powerful
Administrators.
The identification of the security-relevant, internal
system databases and the correlation between each
function and the
corresponding database shall be carefully performed and
documented. The
separation of Operator's and Administrator's functions
shall also lead to
the separation of accessible objects and of access
privileges to shared
databases. This is
an essential design requirement for the enforcement of
the least privilege principle within the TCB because it
helps identify and
eliminate unnecessary Operator access to administrator
data. For example,
the Administrator has full access to system databases
that need not be
fully accessible to the Operator; i.e., the Administrator
has Read/Write
privileges to some (shared) databases, such as the system
security
profile, for which the Operator only needs Read
privileges. Thus, the
Write privilege of the Operator to these databases would
be eliminated.
Also, because these databases are separate, consistency
checks may be
derived from the security-relevant databases of the
Administrator and
applied to the security-relevant functions of the
Operator. This would
increase the robustness of the administrative functions
of the system and,
implicitly, its usefulness.
Figure 1
illustrates both the separation of function and of
privileges/databases for class B2. Note, although the functions of the
Operator and Administrator are completely separated, the
Administrator's
privileges include those of the Operator in the sense
that the
Administrator can always get access to all Operator
functions, databases,
and privileges.
For example, an Administrator can always log in as an
Operator and perform Operator functions. In contrast, the Operator cannot
get access to functions, databases, and privileges that
are exclusively
the Administrator's.
Note, this hierarchical relationship of roles is a
functional hierarchy.
The system could provide a "flat" set of roles,
functions and privileges, and the hierarchy could be
managed
administratively.
4.1.1.
Security-Relevant Functions of the System
Administrator
The
security-relevant functions of the System
Administrator include those that:
*
Define and change the user security
characteristics and those of the system security data
(e.g., user identifier,
user's group identifiers, user/group maximum security
level; and the
maximum/minimum security level of the system data, the
maximum/minimum
security level of each file system).
*
Define and change the system's security
characteristics (e.g., security level limits of
multilevel channels, I/O
processors, communication lines, and devices; all
possible level changes of
single level devices).
*
Perform system programming functions; (e.g.,
trusted system configuration in accordance with the
configuration management
policy, system distribution, system installation, TCB
code maintenance that
may affect system configuration, distribution and
installation).
*
Perform audit functions (e.g., determine what
events should be audited, manage the audit trail, analyze
the audit trail,
produce audit reports).
4.1.2.
Security-Relevant Functions of the Operator
The
security-relevant functions of the Operator include
those that:
*
Enable and disable peripheral
devices, make changes to the device security
characteristics within the limits
defined by the Administrator (e.g., the Operator sets the
level of a
single-level device within the range defined by the
Administrator).
*
Control the mounting of file systems
and load labeled disk packs and tape reels on appropriate
drives.
*
Recover user files following system
crashes.
*
Handle printed output.
*
Perform maintenance operations on
user databases and routine maintenance of TCB databases.
*
Boot up and shut down the system.
4.2. SEPARATION
OF SECURITY AND NONSECURITY-RELEVANT FUNCTIONS
The second
requirement of the trusted facility management is to
identify, audit, and separate the security-relevant
functio