Multics Technical Bulletin MTB-649
B2 Security
To: Distribution
From: Benson I. Margulies
Date: 02/17/84
Subject: A B2 Security Evaluation for Multics
1_ A_B_S_T_R_A_C_T_
After many years of apparent disinterest in computer
security, the DoD has established a Computer Security
Center. This Center has published a "Trusted Computer
System Evaluation Criteria," and is in the process of
evaluating several computer systems. The Criteria set
out requirements for functionality, documentation, and
configuration management for systems at various levels
of security or trust. This MTB briefly describes the
evaluation process, and goes on to discuss the results
to date of the Multics evaluation, including system
changes neccessary to reach the B2 level of the
Criteria.
Comments should be sent to the author:
via Multics Mail:
Margulies at either System-M, MIT, or CISL-SERVICE.
via US Mail:
Benson I. Margulies
Honeywell Information Systems, inc.
4 Cambridge Center
Cambridge, Massachusetts 02142
via telephone:
(HVN) 261-9333, or
(617) 492-9333
_________________________________________________________________
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-649 Multics Technical Bulletin
B2 Security
2_ T_H_E_ E_V_A_L_U_A_T_I_O_N_ P_R_O_C_E_S_S_
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_ T_he C_riteria
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 for modularization of
implementation. The last, "A", requires that formal mathematical
models be used to prove the correctness of the implementation.
The "B" class is in turn split into three levels, B1, B2, B3.
Readers interested in the specifics of 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_ T_he E_valuation P_rocess
To evaluate a system, it is first neccessary to see where its
documented behavior with respect to security conforms Criteria's
levels. Then, it is neccessary to test whether the system
functionally conforms to its documentation. Finally, it is
neccessary to evaluate the system with respect to penetration
resistance and covert channels.
An area of particular concern is called "configuration
management." This term is used to refer to the control of system
changes, source and object libraries, and releases. The Criteria
require that the vendor demonstrate adequate controls on these
areas to insure that future releases of the system continue to
meet the rated level.
_________________________________________________________________
Order number CSC-STD-001-83, often referred to as the "Orange
Book."
Multics Technical Bulletin MTB-649
B2 Security
The DoD wishes to have accurate evaluations of as many vendor
products as possible. The DoD also wishes to avoid the level of
staffing that would be required to do complete evaluations of all
vendor systems. Therefore, the Criteria set requirements for the
vendor in the areas of design documentation and functional
testing. Rather than having to test systems for themselves, the
Center expects to be presented with a set of functional testing
procedures run by the vendor as part of configuration management
that prove that the system behaves as documented.
The evaluation process is not yet complete. The Center has not
yet decided how to manage recertification of new system releases.
It is clear, though, that the requirements for functional
testing, configuration management, and documentation have been
chosen with an eye toward minimizing the effort required to
recertify a system.
2_._3_ T_he S_chedule
The schedule for 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_ M_U_L_T_I_C_S_ D_E_F_I_C_I_E_N_C_I_E_S_
This section lists the functional deficiencies of Multics as
determined by the evaluation team. The later parts of the
evaluation process (functional testing and penetration testing)
may uncover other problems with the system. We expect that these
problems will be appropriately classified as bugs. This list
should be a complete list of deficiencies of the system as
designed.
This section is subsectioned in parallel with the Orange Book,
for ease of reference. Each section begins with the Evaluation
Team's reported deficience, and continuies with explanatory
comments. Sections of the Orange Book where Multics meets the
Criteria are not mentioned.
3_._1_ E_xportation of L_abeled I_nformation (_3_._2_._1_._3_._2_,_ page 2_7_)_
RCPRM does not audit changes in the AIM classification of
volumes and devices.
In general, RCPRM does no useful auditing. See later sections
for specification of the events that should be audited.
MTB-649 Multics Technical Bulletin
B2 Security
3_._2_ L_abeling H_uman-_Readable O_utput (_3_._2_._1_._3_._2_._3_,_ page 2_8_)_
The IO Daemon allows users to over-ride the marking of each
page with the AIM classification of the file printed, but does
not audit this event.
3_._3_ D_evice L_abels (_3_._2_._1_._3_._4_,_ page 2_8_)_
Communications channels do not have both minimum and maximum
AIM classifications.
3_._4_ I_dentification and A_uthentication (_3_._2_._2_._1_,_ page 2_9_)_
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 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
like login. Second, the operators are not identified and
authenticated at all.
The check_acs feature does force a user name and password for
dial and slave requests. However, it does not permit an access
class to be specified, and 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.
3_._5_ T_rusted P_ath (_3_._2_._2_._1_._1_,_ page 2_9_)_
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
disabled.
A "Trusted Path" is a communication 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, causing the user to type information into
files at an innappropriate classification.
Multics Technical Bulletin MTB-649
B2 Security
3_._6_ A_udit (_3_._2_._2_._2_,_ page 2_9_)_
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 are incomplete.
3_._7_ S_ystem I_ntegrity (_3_._2_._3_._1_._2_,_ page 3_0_)_
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_ C_overt C_hannel A_nalysis (_3_._2_._3_._1_._3_,_ page 3_0_)_
We have not provided the team with the results of a covert
channel analysis.
Not surprising, considering that we have not yet done one.
3_._9_ T_rusted F_acilities M_anagement (_3_._3_._3_._1_._4_,_ page 3_8_)_
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_._1_0_ D_esign S_pecification and V_erification (_3_._3_._4_._4_,_ page 4_0_)_
Honeywell has not provided the team with adequate
documentation.
This requires us to claim that Multics still intends to
implement the Bell-LaPadua security model, which we do.
MTB-649 Multics Technical Bulletin
B2 Security
3_._1_1_ C_onfiguration M_anagement (_3_._3_._3_._2_._3_,_ page 3_9_)_
Honeywell has not provided the team with a description of
our configuration management strategy.
3_._1_2_ S_ecurity F_eatures U_ser'_s G_uide (_3_._3_._4_._1_,_ page 3_9_)_
TR's have been submitted by AFDSC specifying those areas
where the existing Multics documentation fails to meet the
Criteria.
3_._1_3_ T_rusted F_acility M_anual (_3_._3_._4_._2_,_ page 3_9_)_
TR's have been submitted specifying those areas where the
existing Multics documentation fails to meet the Criteria.
3_._1_4_ T_est D_ocumentation (_3_._3_._4_._3_,_ page 4_0_)_
Honeywell has not supplied the team with documentation on
Functional Testing procedures.
Not surprising, considering that we have no functional
testing procedures.
3_._1_5_ D_esign D_ocumentation (_3_._3_._4_._4_,_ page 4_0_)_
Honeywell has not supplied the Evaluation Team with adequate
documentation.
Readers are encouraged to look this section up in the Orange
Book. Most of what is required is already present in partial or
innaccurate form in the MPM. We have to make it complete, and
then argue that it meets the requirement.
4_ P_R_O_P_O_S_E_D_ R_E_S_P_O_N_S_E_ T_O_ T_H_E_ D_E_F_I_C_I_E_N_C_I_E_S_
The deficiency list above requires us to do a significant
amount of work. Quite aside from whatever marketing requirement
we may have to "make B2," most of the items are things that we
ourselves would consider deficiencies. For example, it is
certainly a failing of our current development strategies that we
do not maintain a complete and coherent functional test suite for
important system interfaces. Much of what is proposed here could
be justified independently on "quality" grounds.
Multics Technical Bulletin MTB-649
B2 Security
4_._1_ F_unctional T_esting
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 Computer Base. The
Trusted Computer Base is that part of the system which implements
security. For Multics, this is ring zero, ring one, the
Answering Service, the IO Daemon, and the Backup Daemons. All of
these are capable of subverting system security if they have a
bug. For the purposes of the B2 evaluation, the important areas
are rings zero and one and the Answering Service.
Since we lack both a functional test set and the resources
to create one, the Evaluation Team has graciously volunteered to
do most of the work. They are implementing the test interfaces
and exec_coms described below. We are responsable for
integrating them into a coherent package.
4.1.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
Answering Service. 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.1.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.
MTB-649 Multics Technical Bulletin
B2 Security
4.1.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 (preferably a PLM).
4.1.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.
4_._2_ D_ocumentation
The MPM already tries to meet the documentation requirements of
the Criteria. There are, however, a variety of deficiencies that
must be corrected. Further, some of the documentation problems
may turn out to really be code problems, where the documentation
is correct, but the code is wrong.
4.2.1 SECURITY MODEL AND POLICY
The MPM Reference Guide is both incomplete and innaccurate
with respect to security. Not all of the rules are stated, and
some of the things that are stated are misleading or flat wrong.
However, it isn't all the book's fault. The code that implements
the various rules as to what access is required to perform what
operations is, as described below, poorly modularized. In some
cases the system has been enforcing the wrong access restrictions
for years. By rewriting this part of the documentation to be
complete and clear, we will set out (for the first time) what we
intend to implement in this area. Having that intention on
paper, it will be a very small matter to change the programs that
enforce the restrictions to enforce the right ones.
It should be noted that these are not issues of gaping security
holes. These are questions like "What ring should you have to be
in to read the date-time contents modified of a mailbox?"
4.2.2 GATE/INTERFACE DOCUMENTATION
The Criteria require that documentation be available to all
interfaces to the TCB, documented for customers or not. It seems
Multics Technical Bulletin MTB-649
B2 Security
superfluous to point out that a lot of work is wasted in the
project in re-learning how to use gates that are not in the
published documentation because they are "internal," and not in
any internal documentation because we haven't time to maintain or
create it. All ring zero and one gates will be documented with
MPM style documentation as part of this project. There are
several choices for this documentation. We could create an
"Internal Interface PLM." Alternatively, we could document them
with the rest of the subroutines, and mark each page clearly
"Internal interface, subject to change." The important point is
that keeping this documentation up to date must have equal
priority with the supported interfaces.
4_._3_ C_onfiguration M_anagement
Multics already has a perfectly adequate configurement management
system. The process of proposing, reviewing, auditing, and
installing changes meets the Criteria. A site armed with a
previous set of source libraries and compiler can convince itself
that it has indeed received the release it was supposed to, and
nothing else.
Our deficiency is that we do not have the procedure written down
to show the Team. It is neccessary that the MAB's be updated or
written as needed, and made available to the team.
4_._4_ S_ystem C_hanges (_in O_verview)_
This section outlines the changes required to the system to cover
the deficiencies listed above.
4.4.1 AUDITING -- NEW LOGGING FACILITIES
The Criteria require us to audit many more events than we
audit today. Out existing mechanisms for auditing (the syserr
log and the Answering Service log) cannot handle the additional
load and provide reasonable performance. We need to design and
implement a better logging facility. In the long run, the new
mechanism should superceed the existing mechanisms so that all
messages are handled consistently. In the short run, however, we
can replace only the syserr log with the new mechanism and leave
the Answering Service log alone. A future MTB will discuss these
issues in more detail.
MTB-649 Multics Technical Bulletin
B2 Security
4.4.2 AUDITING -- NEW THINGS TO AUDIT
This section describes some of the more important areas
where new auditing is to be added. In general, a pass over the
system adding audit trails where appropriate will have to be
made. These are the areas where significant work will have to be
done to be able to add the audit trails.
4.4.2.1 Successful accesses
The hardcore only audits access violations. The Criteria
require us to audit successful accesses. This implies audit of
each make-known, and of any activation that changes the access
available in the SDW. It also requires audit of all directory
control operations, such as appends, deletes, and acl changes.
4.4.2.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 is 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 us to do more than just add audit messages to
modules. We have to change the interface to the program that
evaluates effective access so that enough information is
available to generate the audit trail.
4.4.2.3 Administration
There is no auditing of security-related administration.
For PDT and SAT AIM fields, we do have the audit trail of the
table installation. It does not tell us what was done, but at
least it identifies the doer. For the PNT we lack even that.
The PNT will have to be moved to an inner ring so that changes to
it can be audited.
Multics Technical Bulletin MTB-649
B2 Security
4.4.3 COMMUNICATIONS CHANNEL AIM
This is by far the most difficult area to understand, though
the actual code changes are not all that bad. The Criteria are
not very specific, but the gaps have been filled by guidance from
the Team. The first part of this section is an expanded
description of the requirements in this area as we have
elucidated them with the team's help. Some of these are
requirements for features of the system, and some of them are
restrictions on how site administrators should use them. The
second part of this section describes the changes to the system
needed to meet the requirements.
4.4.3.1 The Requirement for Communications Channel AIM
4.4.3.1.1 Channels must have AIM ranges
The Criteria require that each channel have an associated
AIM range. This specifies the maximum and minimum classification
of information that may pass over the channel. The crucial
concept here is that this range describes not the channel itself,
but rather the entity(ies) at the other end. Thus,
communications channels are treated like devices. A single level
communications channel is connected to some entity at a
particular authorization. A multi-level communications channel
is connectable to one or more entities each of which has a single
level which is within the range. One might also imagine a
communications connection to a multi-class entity, which would
accept marked data of different classes. As we will see in the
next section, this configuration is not yet defined in the
Criteria.
4.4.3.1.2 Channels are attached at a single level
The Criteria do not yet deal with communications networks.
They do not yet recognize protocols that allow data transmitted
over a network to be marked. Some day, the Center expects to
release a set of Criteria for communications devices and networks
that includes trusted protocols. But for this evaluation, any
attachment of a communications channel is a single level device
at a single authorization. This is precisely the way that RCPRM
handles multi-class devices like tape drives. The drive has a
range of classifications, but any given attachment is at a single
level.
MTB-649 Multics Technical Bulletin
B2 Security
4.4.3.1.3 Multi-class channels are usually inappropriate
While the Criteria allow us to define multi-class channels,
we have to be very clear about when it is appropriate to use
them, both for our customers and ourselves. When a process
attaches a multi-class tape drive at a single level, the
information is actually being transmitted to a single-class tape
volume. Under the Criteria, there could be multi-class volumes,
but there would have to be trusted software to write and read
them. Multics does not have any such trusted software. RCPRM
allows the registration of multi-class volumes, but no site
should ever do so unless they had written a ring one trusted
interface to read and write them. With communications channels,
the system usually has no knowledge of what is on the other end.
If the system has no way of negotiating the access classification
of the other end of the channel, then it is incorrect for the
channel to be given an access classification range.
Administrative documentation will have to warn sites of this.
4.4.3.1.4 Identification and Authentication
Whenever a user is connected to the system, the system must
solicit a user id, password, and access class. In particular,
dial and slave pre-access commands must identify and authenticate
the "user" who gives the command. This requirement obviously
turns a blind eye to computer-computer links. When the Criteria
are extended to include network issues, they will address more
appropriate ways for system to authenticate and identify each
other.
4.4.3.2 Code changes to meet the Criteria
These sections describe the changes to the existing code
needed to meet the requirement above. Some of the changes
described below have already been made as part of the TCP-IP RPQ.
Very few people are familiar with these changes. For clarity,
then, the following sections describe the entire design. They
describe how the system should work, with no reference to how it
works now.
4.4.3.2.1 Identification and Authentication
By site option, the slave and dial pre-access commands will
require the use of the -user control argument. The Answering
Service will prompt for the password of the user name given. The
-access_class control argument will be optional. The user's PNT
and PDT access class restrictions will apply to the access class
Multics Technical Bulletin MTB-649
B2 Security
given with -access_class. For example:
dial internet -user Margulies.Multics -acc system_high
4.4.3.2.2 Extensions to Required Access Class
If a non-privileged process attaches (for dial_out or
priv_attach) a channel, it is implicitly requesting connection to
some entity at the process' current authorization. A privileged
processes can specify an access class other than its current
authorization, subject to the rules for the communications
privilege which is described below. The Answering Service honors
this request as follows: if the channel is single-class, it must
be the requested class. If the channel is multi-class, and a
user has been identified and authenticated via a slave or dial
pre-access command, then that single class specified by the user
on the slave or dial pre-access command line must be the
requested class. If the channel is not associated with a user
via a pre-access command, then the mechanism described below is
used to determine the single access class. Note that the
attachment of a channel that has connected via the accept_dials
mechanism is equivalent to a priv_attach for the purposes of
access class checking.
If the channel is not single-class, and this is a request to
priv_attach a channel, the Answering Service makes a control
order call to the channel called "get_required_access_class". If
the underlying mechanism has some knowledge (due to protocol) or
the access class of the entity on the other end of the channel,
it will return it. This access class becomes the single level
for the purposes of the attachment. If the underlying mechanism
has no such knowledge, then an error code of
error_table_$undefined_order_request will be returned. If a user
was authenticated and identified this error is benign, and the
access class determined from identification and authentication
becomes the single access class of the attachment. If any other
error code is returned, or if no identification and
authentication has taken place (e.g., the channel is in slave
service), then the Answering Service will not honor the request.
It is not valid to attach a multi-class channel unless the access
class of the attachment can be determined.
If, on the other hand, this is a request to dial out a
channel, the Answering service makes a control order call to the
channel of "set_required_access_class." If this control order
succeeds, it means that the underlying communications mechanism
undertakes to guarantee that the other end of the channel is at
that specified access class, and the requested access class
becomes the single level for the attachment. This control order
MTB-649 Multics Technical Bulletin
B2 Security
must succeed for a dial_out of a multi-class channel. If any
error is returned, the request is not honored.
The only standard multiplexer that supports these control
orders is the sty (software terminal) multiplexer. A
set_required_access_class control order made on one end of a sty
sets the access class of the other end. A process dialing out a
sty specifies the access class of the connection, and the process
on the other end sees the channel at that class.
4.4.3.2.3 The comm privilege
As specified so far, all of this mechanism only allow
entities of identical access classes to communicate. To support
the construction of trusted applications, a communications (comm)
privilege is defined. A process with the comm privilege may
attach a communications channel at an accesss class less than or
equal to its authorization. Thus, a process dialing out with the
comm privilege may request that the access class of a channel be
set to any single level less than or equal to the process'
current authorization. A process making a privileged attachment
or accepting dials with the comm privilege may attach any channel
whose access class, as determined by pre-access command,
protocol, or single-class definition, is less than or equal to
the process' current authorization. A process making a
privileged dial_out must specify the desired access class, and it
must be less than or equal to the process' authorization. As
described above, the channel must either be single-class at the
specified class, or multi-class and support
set_required_access_class.
4.4.3.2.4 Summary of access control checks
These diagrams describe the access check for multi-class
channels. In the single-class case, the channel max and min are
the same, and everything between them must be equal to them.
For a priv_attach with a non-privileged process:
-----------------------channel max-------------------------------
unprivileged { user auth from pre-access
process EQUAL to both {
authorization {
{ protocol auth from control
order
-----------------------channel min-------------------------------
Multics Technical Bulletin MTB-649
B2 Security
For a priv_attach with a privileged process:
--------------------process auth---------------------------------
---channel max---
user auth from pre-access EQUAL to protocol auth from control
order
---channel min---
--------------------system_low-----------------------------------
For a dial_out:
--------------------process auth---------------------------------
---channel max---
specified auth
for priv. process
OR
process' auth
for nonpriv. process
---channel min---
--------------------system_low----------------------------------
4.4.4 FILE SYSTEM
The changes to the file system proper are small but
important. As described above, there are currently open
questions about the access decisions made and error codes
returned by some of the file system interfaces. Once we clear up
the documentation, we can make the minor code changes to make the
behavior of the code conform to the documentation.
An area of particular concern is obsolete interfaces. The
retention of obsolete interfaces adds to the burden of functional
testing. Where possible, these should be removed. If they
cannot be removed, they should be removed from the supervisor.
There are two approaches to this. Where we have two different
hardcore programs that implement the same thing (e.g. acl.pl1
and asd_.pl1 for acls), we can replace the old program with a
MTB-649 Multics Technical Bulletin
B2 Security
stub that calls the new program. It is arguable that if the stub
calls the same entrypoints as the gates to the new interfaces
that seperate testing of the old gate interfaces will not be
required. Designing a way to redirect calls to certain entries
of a gate to a user ring stub would be even better. This could
be done with a linkage error handler and a feature of the gate
actor that returned the name of the replacement program.
4.4.5 BETTER CONTROL OF PRIVILEGES
Currently, access to privileges is an all-or-nothing affair.
It should be possible, for example, to give a process access to
the comm privilege withoput giving it seg or dir. This can be
arranged by making system_privilege_ a gate to ring one that
checks acs's. By putting the acs's into >sl1 (and therefore on
the system tape), and links in >sc1>rcp, this mechanism can be
guaranteed to work in the face of file system damage.
4.4.6 THE ALL-POWERFUL OPERATOR
Future MTB's will describe limited command subsystems for
the Hierarchy and Volume Backup daemons, and for an
authentication mechanism for operators.
4_._5_ C_overt C_hannels
The Criteria require us to make and document a covert
channel analysis for covert storage channels. A memo has already
been circulated describing the process of making this analysis.
It will be published as an MTB.
5_ F_U_T_U_R_E_ D_I_R_E_C_T_I_O_N_S_
This section presents some thoughts on where we go after we
make B2. At this time, they represent the author's personal
opinion, and should not be held against anyone else.
5_._1_ A_ttitude
There are some general principles of design and
implementation. We should try to apply them consistently to the
entire system.
Multics Technical Bulletin MTB-649
B2 Security
5.1.1 TESTING IS IMPORTANT
For one last time in this MTB, I will point out that our
current lack of testing technology is little short of criminal.
It contributes to our tendency to ship buggy code. It makes it
difficuly to detect inadvertent functional regressions. Worse
yet, people often think that they cannot afford to spend the time
to build real, permanent, testing technology. At best, they
arrange an ad-hoc test methodology and let it go, leaving the
next maintainer to repeat the exercise. At worse, they just
depend on exposure to find the problems.
5.1.2 DESIGN FOR ASSURANCE
It is possible to design software to be testable. It is
possible to introduce special code paths that exercise features
that are normally exercised only under extraordinary
circumstances. It is possible to put in test features that take
faults in uncomforable places. All of this could be part of our
coding standards.
5.1.3 SECURITY-RELATED MODULARIZATION --> IMPROVED QUALITY
The B2 criteria call for code modularization of the TCB to
make it possible for evaluation team to really convince
themselves that things work without reading every line of every
program. The B3 criteria make more demands in this area. This
kind of modularization produces a higher quality product for our
users. It makes it quite unlikely that the code will suffer from
defects involving incorrect access control decisions, because all
such decisions would be made in a central place.
5_._2_ S_ecurity C_oncerns
Focusing on the area of security functionality, there are
two areas we can persue in the future.
5.2.1 MEETING THE SPIRIT OF B2
Due to lack of time, the evaluation process is not paying
much attention to several trusted ring one applications,
particularly the dumpers. It is important that these
applications be brought up to the same functional standards as
the rest of the system. For example, we should be able to
demonstrate that the Hierarchy Dumper / Retriever will always
reload information at the access class it had when it was dumped.
MTB-649 Multics Technical Bulletin
B2 Security
5.2.2 MAKING B3
Multics is not far from B3. We already have features
required for B3 and not required for B2. It is not unreasonable
to set a goal of making a B3 rating in the next few years. B3 is
the highest rating that can be achieved without the use of formal
mathematical methods that are just barely practical at this time,
and which can probably never be applied after the fact.
5.2.2.1 This is NOT Guardian
I want to make it quite clear that the GUARDIAN proposal,
which called for the removal of all pathname management from ring
zero, is not required to make B3, and is not proposed here.
5.2.2.2 Centralize Access Control Decisions
The single largest barrier to a B3 rating for Multics is the
ad-hoc manner in which access control decisions are made in the
file system. The B3 criteria would require us to make a single
module which answered "yes" or "no" to any request for access to
an object, and supplied the correct error code to return to the
user in case of a "no." This module would be responsable for all
audit trails.