Guide To Understanding Trusted Facility Management
Guide To Understanding Trusted Facility Management
Guide To Understanding Trusted Facility Management
June 1989
Page 1
NATIONAL COMPUTER SECURITY CENTER
NCSC-TG-O15
Library No. S-231, 429
FOREWORD
_______________
Patrick R. Gallagher Jr. 15 August 1989
Director
National Computer Security Center
Page 2
ACKNOWLEDGEMENTS
Page 3
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.
Page 4
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
Page 5
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
GLOSSARY 47
REFERENCES 58
Page 6
LIST OF FIGURES
Page 7
1. INTRODUCTION
1.1. PURPOSE
1.2. SCOPE
Page 8
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.
Page 9
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].
No Additional Requirements.
3.1.2. Accountability
Page 10
* must satisfy the modularity requirements of class B2;
* System Programmer
* the Auditor
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.
Recommendation:
Page 11
TCB functions and interfaces implementing administrative roles as stated.
3.1.5. Documentation
Page 12
interfaces of the administrative roles;
Recommendation:
No Additional Requirements.
3.2.2. Accountability
Recommendations:
Page 13
distinguish among
* their privileges
* their databases.
* Security Administrator;
* Auditor;
* Secure Operator;
* Account Administrator;
* Operator.
Recommendation:
Page 14
No Additional Requirements.
3.2.5. Documentation
No Additional Requirements.
No Additional Requirements.
Page 15
"The TCB shall support separate Operator and Administrator
functions."
Page 16
vulnerable state.
Page 17
* Perform audit functions (e.g., determine what events should be
audited, manage the audit trail, analyze the audit trail, produce audit
reports).
* Control the mounting of file systems and load labeled disk packs
and tape reels on appropriate drives.
Page 18
higher degree of trust implies that the operational and life-cycle assurance
tasks are more extensive than those necessary for functions of a lower level
of trust. Although some nonsecurity-relevant functions of the Administrator
may be functionally a part of the TCB in class B2, flaws in these functions
should lead only to potential denial-of-service instances, but not to security
or integrity violations. In class B3, essentially where the nonsecurity-
relevant functions of the Administrator shall be removed from the TCB. The
TCSEC does permit the inclusion of nonsecurity relevant functions that are
essential to performing the security role. While the separation of
administrative functions is not required below class B2, the benefits and
protection it provides should be seriously considered.
Page 19
are discussed in the section entitled, "TCSEC Requirements For Trusted
Facility Management."
(2) by the need to divide the power (e.g., privileges) of the all-
encompassing Administrator duty into multiple roles that incorporate different
levels of trust,
Page 20
Administrator, Account Administrator, Operators). The separation of the
Auditor's functions, databases, and access privileges from those of the
Security Administrator, Account Administrator, and Operators is an important
application of the separation of privilege and least privilege principles.
Should such separation not be performed, and should the Security Administrator
be allowed to undertake Auditor functions or vice-versa, the entire security
function would become the responsibility of a single, unaccountable individual
or role in normal mode of system operation. For example, a Security
Administrator may take actions that represent misuse of authority and then use
Auditor functions to erase any evidence of his actions. Although this is
obviously undesirable, the TCSEC does not require the separation of Security
Administrator and Auditor functions (and neither does it require the
separation between Secure Operator and Operator functions).
(2) who defines the user and the system security characteristics,
Page 21
5.1. FUNCTIONS OF THE SECURITY ADMINISTRATOR
* maximum login time (maximum amount of time the user may remain
logged in to a system);
[Note: The above decisions are made when the system is installed
for a particular organization, and the system Security Administrator carries
out the installation decisions made by that organization.]
Page 22
The definition of user account and registration profile; this
definition may include:
* group statistics.
Page 23
Administrator may include the following:
* file (device) system name table and file (device) mount tables;
Page 24
Delete user/group accounts.
[Note: Shutting down the system requires that the Operator ensure
that appropriate physical and administrative security features be in place
to protect the information while the system is not running. For example,
shutting down for maintenance might require that the date be removed and the
system cleared.]
Page 25
process identifies damaged labels (e.g., labels inconsistent with those of
containing directories and files) and deletes all access to the
corresponding objects until repair is finished by the System Programmer and
Security Administrator.
* security-map backup;
It must be noted that the Operator should not have the privilege
to modify file contents for file backup.
Page 26
the Account Administrator.
* system availability;
* system configuration;
* disk/CPU/memory statistics.
Page 27
pathnames are interpreted, should be audited. (An object-unique name is the
unique name that identifies and distinguishes a particular object from all
other objects in a system. In a hierarchical file system, the object-unique
name includes the associated directory names so users can use the same name
for objects in different directories). Otherwise, audit analysis tools that
read audit events recorded after a directory change cannot identify objects
unambiguously. For similar reasons, all events that record process creation
or destruction and identification or authentication actions should be selected
whenever the audit is on.
Page 28
If the audit log becomes full and the audit mechanism is on, then the system
may stop and delay further activity until the Auditor takes corrective
action [7].
Functions that format and compress events in the audit log and
postprocessing audit files. The formatting functions may convert binary audit
data into text format, and combine partial event records into the required
record format. The storing of formatted postprocessing files may require
the use of compression techniques to improve storage utilization.
The setting of the default and current values of the delays for
single covert channels or for groups of covert channels.
In summary, the functions of the Auditor role may set up, access
and modify the following types of databases:
Page 29
* formatted or compressed audit files containing the input to
the postprocessing phase;
The functions of the System Programmer role are the most security-
sensitive functions of the system. They may affect the TCB configuration,
distribution and maintenance. These functions are not necessarily audited
and, thus, any error, omission, or malicious act, which affects the security
of the entire system, may remain undetected. (However, some form of auditing,
possibly off-line, is still necessary in some environments. Multiple
Systems Programmers checking each others' actions may also be required in some
environments for the execution of the System Programmer functions.
Furthermore, a two-person rule may be instituted or built into the login
procedure requiring that a System Programmer may not log in successfully
unless another System Programmer is also logging in). Thus, the System
Programmer functions should have the highest degree of trust in the system.
The System Programmer functions may include the following:
Page 30
2. Setting of system configuration parameters (as specified by
the site's configuration management policy); for example, this includes:
* analysis of dumps;
* installation of "patches" to the TCB code and data (for this the
Operator should be able to recompile TCB code from modified source code and
should use a trusted loader to reload the system);
Page 31
the attributes of objects and security profiles of users in
other roles and, if necessary, to log in and take actions in that role.
* access privileges;
* size;
* ownership.
* passwords;
Page 32
use some of the security mechanisms and policies of the underlying system to
implement some of their special protection requirements or may choose to
implement new protection mechanisms and policies. For example, the
implementors of Security Administrator functions may use the discretionary
access control mechanisms or may choose to implement to protect the Security
Administrator databases from other administrative users and from normal users.
This section examines the relationship of other TCSEC requirements to
trusted facility management.
Page 33
guidelines (see example,[9]).
6.2. ACCOUNTABILITY
6.3. ASSURANCE
Page 34
structuring, such as those of modularity, abstraction, information hiding, and
layering apply to the design and implementation code of the programs and
processes of trusted facility management. Careful analysis and
documentation of this design and implementation area, as well as careful
scrutiny by evaluators, is expected in this area.
Page 35
interfaces applies as stated. However, the requirements for a formal model,
for an interpretation of this model in the DTLSs of the trusted facility
management part of the TCB, and for a convincing argument that the DTLSs are
consistent with the model are not directly applicable here. The reason for
this is that no generally acceptable formal model of the trusted facility
management area exists to date. Should a generally acceptable formal model
become available, then all requirements of the design specification and
verification area would apply to trusted facility management directly.
6.4. DOCUMENTATION
Page 36
GLOSSARY
Access
Account Administrator
Administrative User
Administrator
Approval/Accreditation
Audit
Audit Mechanism
Audit Postprocessing
Audit Trail
Page 37
procedure, or an event in a transaction from its inception to final results.
Auditable Event
Auditor
Authenticate
Authenticated User
Bandwidth
Category
Channel
Covert Channel
Page 38
A communication channel that allows a process to transfer
information in a manner that violates the system's security policy. See
also: Covert Storage Channel, Covert Timing Channel.
Data
Data Integrity
Page 39
Formal Top-Level Specification (FTLS)
Functional Testing
Least Privilege
Multilevel Device
Multilevel Secure
Object
Object-Unique Names
Page 40
object-unique name includes the associated directory names so users can use
the same name for objects in different directories.
Operator
Output
Password
Process
Read
Secure Operator
Security Administrator
Security Level
Page 41
The combination of a hierarchical classification and a set of
nonhierarchical categories that represents the sensitivity of information.
Security Policy
Security-Relevant Event
Security Testing
Sensitive Information
Sensitivity Label
Separation of Privilege
Spoofing
Page 42
user. Also called masquerading or mimicking.
Subject
System Administrator
System High
The security label that dominates all other security labels in the
system. In a sense, it is the highest possible label.
System Low
System Programmer
Trap Door
Trojan Horse
Page 43
Trusted Computer System
Trusted Path
User
Verification
Virus
Vulnerability
Write
Page 44
Write Access (Write Privilege)
Page 45
REFERENCES
4. Bishop, M., "How to Write a Setuid Program"; login, vol. 12, no. 1,
January/February 1987.
12. Gligor V.D., C.S. Chandersekaran, R.S. Chapman, L.J. Dotterer, M.S. Hecht,
W.D. Jiang, A. Johri, G.L. Luckenbaugh, and N. Vasudevan, "Design and
Implementation of Secure Xenix," IEEE Trans. on Software Engineering, vol. SE-
13, No. 2, February 1986.
13. Gligor V. D., J.C. Huskamp, S.R. Welke, C. J. Linn, and W.T. Mayfield,
"Traditional Capability-Based Systems: An Analysis of their Ability to Meet
the Trusted Computer Security Evaluation Criteria," Institute for Defense
Analyses, IDA Paper P-1935, February 1987
14. Hecht M.S., M.E. Carson, C.S. Chandersekaran, R.S. Chapman, L.J. Dotterer,
V.D. Gligor, W.D. Jiang, A. Johri, G.L. Luckenbaugh, and N. Vasudevan, "Unix
Without the Superuser," Proc. of the Usenix Conference, Phoenix, Arizona, June
1987.
Page 46
15. Intel Corp., iAPX 286 Programmers Reference Manual, Chapter 7, section
5, Intel Corp., 1983.
16. Knowles, F., and S. Bunch, "A Least Privilege Mechanism for Unix," Proc.
of the 10th Na*tional Computer Security Conference, Baltimore, MD.,
September 1987.
19. Schroeder, M.D. and J.H. Saltzer, "A Hardware Architecture for
Implementing Protection Rings," Communica*tions of the ACM, vol. 15, no. 3,
March 1972.
Page 47