Multics Technical Bulletin MTB-662
B2 Security
To: Distribution
From: Pozzo, Margulies
Date: 07/02/84
Subject: A B2 Security Evaluation for Multics - Revised
1 ABSTRACT
This documents the current status of the Multics
Security Evaluation. Section 2 describes the
evaluation process with some notes about the Department
of Defense Trusted Computer System Evaluation Criteria
(The Criteria). Sections 3 and 4 are devoted to
Multics functional deficiencies found by the team and
Honeywell's response to these deficiencies. Section 5
details the schedule for implementing the changes
required to cover the deficiencies. This MTB, in
addition to informing the Multics community of its
contents, serves as a formal response to the DOD
Security Evaluation Team, informing them of Honeywell's
plans for resolution of the deficiencies found by the
team.
Comments should be sent to the author:
via Multics Mail:
Pozzo.Multics on either MIT Multics or System M.
via US Mail:
Maria M. Pozzo
Honeywell Information Systems, inc.
575 Tech Square
Cambridge, Massachusetts 02139
via telephone:
(HVN) 261-9364, or
(617) 492-9364
_________________________________________________________________
Multics project internal working documentation. Not to be
reproduced or distributed outside the Multics project without the
consent of the author or the author's management.
MTB-662 Multics Technical Bulletin
B2 Security
2 THE EVALUATION PROCESS
The DoD's intent is to make it possible for computer users inside
and outside of the DoD to specify the level of security that they
need, and to find systems that satisfy those specifications with
"on-the-shelf" products of vendors. To that end, they have
published the Criteria, and established an evaluation process.
2.1 The Criteria
The Criteria describe four broad classes of computer systems.
The first, "D", is reserved for those systems that do not meet
even mimimal requirements for secure computer systems. These are
effectively unsecured systems. The second, "C", requires
discressionary and password access controls. The third, "B",
includes all of the requirements for "C", and adds requirements
for nondiscressionary control and modularization of
implementation. The last, "A", requires that formal mathematical
models be used to prove the accordance of the design to the
security policy.
The "B" class is in turn split into three levels, B1, B2, B3.
Readers interested in the differences between them are referred
to the Criteria. Multics is thought to be best described as a B2
system. However, there are a number of problem areas that, if
left uncorrected, would leave it in the "C" class.
2.2 The Evaluation Process
The evaluation process of a system involves several phases. It
is first necessary to examine the documentation and determine
where the system, as documented, conforms to the levels of the
Criteria. It is then necessary to test whether the system
conforms functionally to its documentation. The final step is to
evaluate the system with respect to penetration resistance and
covert channels.
The Criteria requires that the vendor demonstrate adequate
controls over system changes encompassing source and object
libraries, test suites and documentation. This "configuration
management strategy" is necessary to assure future releases of
the system meet the rated level.
_________________________________________________________________
Order number CSC-STD-001-83, often referred to as the "Orange
Book."
Multics Technical Bulletin MTB-662
B2 Security
The evaluation process is not yet complete. The Center has not
yet decided how to manage re-certification of new system
releases. It is clear, however, that the requirements for a
configuration management strategy, particularly those for
functional testing and documentation, have been chosen with an
eye toward minimizing the effort required for re-certification.
2.3 The Schedule
At this writing, the evaluation team is in the penetration
testing phase and anticipate completion within the next several
weeks. The schedule for the remainder of the evaluation is
uncertain as of this writing. However, it is currently intended
to make the B2 rating apply to MR11. Thus, any code and
documentation changes described here are intended for an MR11
shipment.
3 MULTICS DEFICIENCIES
This section lists the functional deficiencies of Multics as
determined by the evaluation team after a thorough examination of
available documentation. The later parts of the evaluation
process (functional testing and penetration testing) may uncover
additional system weaknesses and bugs.
This section is subsectioned in parallel with the Orange Book,
for ease of reference. Each section begins with the Evaluation
Team's reported deficiency, and continues with explanatory
comments. Sections of the Orange Book where Multics satisfies
the Criteria are not mentioned.
3.1 Exportation of Labeled Information (3.2.1.3.2, page 27)
Although the creation of multi-class tapes is supported, the
tapes cannot be used unless rcp_priv is turned on in the
accessing process or the process is running in ring-1.
RCPRM, the part of the TCB which controls devices, does not audit
changes in the AIM classification of volumes and devices. See
Section 4.6 Audit.
3.2 Labeling Human-Readable Output (3.2.1.3.2.3, page 28)
The AIM classification of the file printed is marked on top and
bottom of page. The IO Daemon allows users to over-ride this
marking but does not audit this event.
MTB-662 Multics Technical Bulletin
B2 Security
3.3 Device Labels (3.2.1.3.4, page 28)
Communications channels do not have both minimum and maximum AIM
classifications.
3.4 Identification and Authentication (3.2.2.1, page 29)
All users connected to the system must be identified (via a
user-id) and authenticated (via a password). This verification
must be performed by the system mechanism designed for that
purpose. Multics is deficient in two ways. First, dial and
slave pre-access commands do not allow an access class to be
specified as is the case with login. Second, operators are not
identified or authenticated in any way.
The check_acs feature does force a user name and password for
dial and slave requests but does not associate an authenticated
name with future actions. In addition, it does not compare the
default/maximum authorization of the user name supplied in the
PNT against the channel and the process attaching the channel.
When not in admin mode, no name/password is solicited from the
operator. In addition, the PNT is located in ring-4, increasing
the risk of compromise. See Section 3.6 Audit.
3.5 Trusted Path (3.2.2.1.1, page 29)
The Trusted Facilities documentation must describe the importance
of DTR in achieving a trusted path to the answering service. The
-auth control argument of new_proc must be able to be disabled as
a site option.
A "Trusted Path" is a communication path to the "system" that is
guaranteed to be un-cooptable by a trojan horse. A trusted path
must be available for all requests for changes in access
authorization, password, etc. The only trusted path currently
implemented in Multics is the connection to the answering service
that you get when your terminal drops DTR, and the hangup causes
the Answering Service to take your line. A trojan horse could
simulate new_proc (i.e., create a new process at a different
authorization, without the user's knowledge), causing the user to
type information into files at an inappropriate classification.
The same holds true for the -hold control argument to logout.
Thus, the -hold argument must also be able to be disabled as a
site option.
Multics Technical Bulletin MTB-662
B2 Security
3.6 Audit (3.2.2.2, page 29)
Multics fails to audit a variety of events covered by the
description in the Criteria in this section. In particular,
system administration and RCPRM do no useful auditing, the
hardcore does not audit successful accesses, and many audit
trails, particularly administrative, are incomplete. In
addition, because the PNT is located in ring-4, it is impossible
to audit changes to it.
3.7 System Integrity (3.2.3.1.2, page 30)
Honeywell has not supplied the Team with a description of T&D and
related items to allow them to satisfy themselves that a site can
validate the operation of the hardware and firmware.
3.8 Covert Channel Analysis (3.2.3.1.3, page 30)
The team has not been provided with the results of a covert
channel analysis.
3.9 Trusted Facilities Management (3.3.3.1.4, page 38)
The Multics operator is "all powerful." It must be possible to
prevent the operator from using security administration, or
otherwise compromising the security of the system, due to access
to facilities not needed to operate the system.
There are two problems here. First, the restricted operator
environment includes the logical volume administration commands,
which (a) can be used to change the AIM restrictions on volumes,
and (b) are not needed in normal operation. Second, the operator
has complete control over the Dumper daemons, which (a) have
access to privileged facilities, and (b) are sitting at normal
Multics command level most of the time.
3.10 Design Specification and Verification (3.3.4.4, page 40)
Honeywell has not provided the team with adequate documentation.
This includes a claim that Multics implements the Bell-LaPadula
security model.
MTB-662 Multics Technical Bulletin
B2 Security
3.11 Configuration Management (3.3.3.2.3, page 39)
Honeywell has not provided the team with a description of our
configuration management strategy.
3.12 Security Features User's Guide (3.3.4.1, page 39)
TR's have been submitted by AFDSC on behalf of security
specifying those areas where the existing Multics documentation
fails to meet the Criteria. All the security-related commands
must be documented in one place; possibly with references to
other documentation where more detailed information can be found.
This document should identify the implications of exercising the
different commands and their options with regards to security.
3.13 Trusted Facility Manual (3.3.4.2, page 39)
TR's have been submitted specifying those areas where the
existing Multics documentation fails to meet the Criteria.
Privileged commands of both operators and administrators must be
documented.
3.14 Test Documentation (3.3.4.3, page 40)
Honeywell has not supplied the team with documentation on
Functional Testing procedures.
3.15 Design Documentation (3.3.4.4, page 40)
Honeywell has not supplied the Evaluation Team with adequate
design documentation. Readers are encouraged to read the
appropriate section in the Orange Book for more information on
what is required.
4 PROPOSED RESPONSE TO THE DEFICIENCIES
The deficiency list above requires a significant amount of work.
Quite aside from whatever marketing requirement Honeywell may
have to "make B2", most of the items are things that, in general,
would be considered deficiencies. For example, it is certainly a
failing of current development strategies that a complete and
coherent functional test suite for important system interfaces is
not maintained. Much of what is proposed here could be justified
independently on "quality" grounds.
Multics Technical Bulletin MTB-662
B2 Security
This section is subsectioned in parallel with section 3 "Multics
Deficiencies", and details Honeywell's response to each of the
items mentioned as well as changes required to the system to
cover these deficiencies.
4.1 Exportation of Labeled Information
Since the use of multi-class tapes is not a feature provided with
the system, this is not a problem.
4.2 Labeling Human-Readable Output
The IO Daemon will be modified to disallow over-riding of page
labels as the default. Since this will be site-settable, in
systems where it is allowed, over-riding of page labels will be
audited.
4.3 Device Labels
Work on Communications Channel AIM has already begun and is
detailed in a separate MTB.
4.4 Identification and Authentication
Much of this work falls under the work being done for
Communications Channel AIM. In addition, the PNT will be moved
to ring-1. Furthermore, modifications will be made to require
identification and authentication of operators.
4.5 Trusted Path
As the default, new_proc -auth and logout -hold will be disabled.
This will be a site-settable parameter.
4.6 Auditing -- New Logging Facilities
The Criteria require that many more events be audited than is
currently audited. Existing mechanisms for auditing (the Syserr
log and the Answering Service log) cannot handle the additional
load and provide reasonable performance. A better logging system
needs to be designed and implemented. In the long run, the new
mechanism should supersede the existing mechanisms so that all
messages are handled consistently. In the short run, however, it
is feasible to replace only the syserr log with the new mechanism
MTB-662 Multics Technical Bulletin
B2 Security
while leaving the Answering Service log alone. A future MTB will
discuss these issues in more detail.
4.6.1 AUDITING -- NEW THINGS TO AUDIT
This subsection describes some of the more important areas where
new auditing is to be added. In general, an examination of the
system, adding audit trails where appropriate, must be completed.
4.6.1.1 Successful Accesses
Hardcore only audits access violations. The Criteria require
auditing successful accesses. This implies audit of each
make-known, make-unknown and of any activation that changes the
access available in the SDW. It also requires audit of directory
control operations, such as appends, deletes, ring changes and
acl changes. In addition, a site must be able to set an audit
threshold for levels or categories for both persons and projects.
This feature will be added.
4.6.1.2 RCPRM Access Decisions
RCPRM has the opposite problem. It leaves behind a syserr
message each time a resource is reserved, assigned, attached,
detached, unassigned, or unreserved, but leaves no record of
access refusals. The audit trails that it does leave contain no
access information.
This is a bigger problem than it looks. The code structure of
RCPRM makes all the real access decisions in a module that has
limited knowledge of what operation is taking place. The calling
modules that know what is going on do not know why the access was
denied, only that the user lacked sufficient effective access.
This requires more than just adding audit messages to modules.
The interface to the program that evaluates effective access must
be changed so that enough information is available to generate
the audit trail.
4.6.1.3 Administration
There is no auditing of security-related administration. For PDT
and SAT AIM fields, the audit trail of the table installation
does exist. It does not indicate what was done, but at least it
identifies the doer. For the PNT, even that is missing. The PNT
will have to be moved to an inner ring so that changes to it can
be audited (see Identification and Authentication, Section 4.4).
Multics Technical Bulletin MTB-662
B2 Security
4.7 System Integrity
Honeywell will provide the team with statements of confidence
that assure the correct functioning of the CPU/SCU, IOM, IO
Devices, MPC and the FNP. Honeywell will be receiving a list
from the team of what the statements of confidence should cover
specifically. In addition, Honeywell will provide the team with
the instruction book for running tests on these components
(called the "ditty books").
4.8 Covert Channel Analysis
As part of the plans for MR11, a Covert Channel Analysis will be
completed and documented by Honeywell. Channels that cannot be
closed, will be audited, noised up, etc.
4.9 Trusted Facilities Management
Towards this effort, change_vol_registration will be removed from
the admisitrator process. A limited service subsystem will be
provided for use in the daemon process running hierarchy backup.
This interface will restrict the set of commands available to the
operator to only those required for backup functions. In
addition, quits will be disabled for the daemon running this
process. Furthermore, no daemons will sit at Multics command
level. The documentation will state that operators should not be
allowed to run hierarchy retrievers at a highly secure site.
4.10 Design Specification and Verification
The MPM Reference Guide is both incomplete and inaccurate with
respect to security. Not all of the rules are stated, and some
of the things that are stated are misleading or wrong. It is
necessary to state the security model that Multics implements,
that being the Bell and LaPadula Model.
Towards this effort, Chapter 6 of the MPM Reference Guide, Access
Control, will be re-written to clearly describe the security
policy implemented. An outline for this new chapter is being
prepared for submission to the team. In addition, the
interafaces to the TCB are being defined in several categories.
There will be two sets: those for public release and privileged
interfaces. Ultimately, the DTLS will include the subroutine
manual description for each of the defined interfaces. For those
interfaces which are gates, there will be three types: available
for current use; available for current use by systems'
MTB-662 Multics Technical Bulletin
B2 Security
programmers; not recommended for current use. The documentation
will accurately reflect to which category a gate belongs.
4.11 Configuration Management
In the past, changes to Multics were accomplished by proposing,
reviewing, auditing, and installing the changes. A site armed
with a previous set of source libraries and compiler could
convince itself that it had indeed received the release it was
supposed to, and nothing else.
The deficiency is that the procedure is not written down. A
configuration management strategy has been prepared and submitted
to the team for approval.
4.12 Security Features Users' Guide
A chapter will be prepared that will contain a list of all the
security related commands and a brief description of their
functions and where to locate more detailed information. This
chapter will become part of the MPM Reference Guide.
4.13 Trusted Facility Manual
A new System Administrators Users' Guide is being prepared. This
information will be contained in that set of documents. An
outline is currently being prepared.This is expected to be
complete by MR11.
4.14 Test Documentation
There is currently no set of tests that can be run to verify the
functional operation of Multics. The Criteria require that
functional tests exist for the entire Trusted Computing Base.
The Trusted Computing Base is that part of the system which
implements security. For Multics, this is ring zero, ring one,
and all privileged applications (i.e. the Answering Service).
All of these are capable of subverting system security if they
have a bug.
Since both a functional test set and the resources to create one
are lacking, the Evaluation Team has graciously volunteered to do
most of the work. The team has implemented a good majority of
the functional test suite. Honeywell will be responsible for
completing the test suit in conjunction with the team and
Multics Technical Bulletin MTB-662
B2 Security
integrating the tests into a coherent package. The following
subsections further describe the tests.
4.14.1 TEST STRUCTURE
The test set will consist of interface programs and scripts.
There will be one interface program per software interface.
Almost all of the software interfaces are gates to ring zero and
ring one. The others are the software-callable interfaces to the
various privileged applications. These interface programs are
minimal commands that translate command language into arguments
suitable for the gate.
The scripts are sets of calls to the interfaces that exercise
their functionality. When possible, they are exec_coms.
However, some scripts of commands require the use of processes at
different authorizations. For these, a benchmark driver system
(already existing) will be used to drive software terminals.
4.14.2 TEST PROCEDURES
Test procedures will consist of a series of runs of the scripts.
By and large, the scripts will use compare_ascii technology to
detect deviations from the correct behavior. However, some
things (like log messages) are not really amenable to automatic
verification, and will have to be verified by hand by the people
running the test. Of course, the results of the first run of the
tests will have to be manually verified.
4.14.3 TEST RESULTS
The final results of the functional testing project are the
documentation describing the tests, the procedures for running
the tests, and a reference set of test output. The documentation
of the tests and their procedures should be maintained in a
reasonable format (possibly a PLM).
4.14.4 LONG-TERM IMPLICATIONS
For functional testing to have any point, there has to be a
management commitment to maintain and upgrade the tests as the
system changes, and to require developers to run the tests when
they change the system. This is part of the configuration
management plan proposed.
MTB-662 Multics Technical Bulletin
B2 Security
4.15 Schedule
The following is an overview description of the requirements to
meet B2 with MR11. The effort required is in terms of man-weeks
required. In two areas, Functional Testing and Design
Documentation, some of the effort required has been accounted for
in section A (*). For example, it is estimated that it will
require 27 mw of effort to complete the functional testing. Of
those 27 mw, 7 of them involve creating and running functional
tests for some of the areas mentioned in section A. A more
detailed schedule is available.
Multics Technical Bulletin MTB-662
B2 Security
A. Remedy Functional Deficiencies Effort
1. Auditing 23
2. Communications Channel AIM 8
3. Directory Control 8
4. Operator Environment 16
5. Change new_proc -auth and logout -hold 1
6. IO Daemon Override Label 1
----
57
B. Fix Bugs Discovered by DODCSC and CISL during
Functional Testing
1. Functional Testing 20 + 7*
a. Completion of CISL portion of 12
Functional Tests
b. Fix bugs found by CISL and DODCSC 8
2. Penetration Testing 12
a. Fix Security-related bugs ASAP 4
b. Respond to flaws found by Team 3
c. Resolve remaining bugs 5
3. Covert Channel Analysis 8
a. Perform CISL Covert Channel Analysis 4
b. Determine status of all identified
channels 2
c. Resolution of channels 2
----
40
C. Security-Related Documentation
1. Descriptive Top-Level Specification (DTLS) 11
a. Reference Manual description of security
policy and model 2
b. Trusted Computing Base (TCB) Interfaces 9
2. Security Features Information 4
3. Design Documentation - PLMs 28 + 8*
a. All TCB Components
4. Trusted Facilities Manual 8
----
51
D. Change Control Procedures
1. Configuration Management Plan NA
TOTAL = 148mw OR 36mm