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

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

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

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

     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

     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

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

     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.


     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

     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.


     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


     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).


    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.


     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?"


     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.


     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


     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. 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. 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. 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


     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. The Requirement for Communications Channel AIM 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. 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

MTB-649                                Multics Technical Bulletin
                                                      B2 Security 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. 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. 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. 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 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. 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. 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
-----------------------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
                 ---channel min---


     For a dial_out:

--------------------process auth---------------------------------

                 ---channel max---

                  specified auth
                 for priv. process


                   process' auth
                for nonpriv. process

                 ---channel min---



      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.


     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.


     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


     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.


     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.


     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.


     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. 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. 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.