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