Multics Technical Bulletin                                MTB-657
Backup Dumper Subsystems

To:       Distribution

From:     Benson I.Margulies

Date:     05/11/84

Subject:  Limited Subsystems for the Hierarchy and Volume Backup Dumpers

1_ A_B_S_T_R_A_C_T_

          It should not be  neccessary to trust Multics
          operators  as System  Security Adminstrators.
          However,   the   current  interface   to  the
          hierarchy  and  volume   dumpers  allows  the
          operator unrestricted  use of a  process with
          access  to  privileged  gates.   A  malicious
          operator, using the Backup.SysDaemon process,
          can arbitrarily and  invisibly subvert system
          security.   This  MTB   describes  a  limited
          subsystem for the volume and hierarchy backup
          processes  that  eliminates this  risk.  This
          MTB  proposes  two  options  for  the command
          repetoire of the subsystem.  When a consensus
          is   reached  a   revision  will   be  issued
          describing only the definitive design.

Comments should be sent to the author:

via Multics Mail:
   Margulies at either System-M, MIT, or CISL-SERVICE.

via Forum:
   >udd>m>mtgs> on System-M

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-657                                Multics Technical Bulletin
                                         Backup Dumper Subsystems

2_ I_N_T_R_O_D_U_C_T_I_O_N_ -_-_ T_H_E_ D_U_M_P_E_R_S_

Both the  hierarchy and volume backup  dumper processes introduce
unacceptable security flaws in an operating Multics system.  They
are  examined  here  in  turn.   The  hierarchy  dumper  requires
considerable  access to  do its  work.  It  depends on  access to
hphcs_ and  ACL access to all  objects to be dumped,  and runs in
ring  1.   Since  it runs  in  an ordinary  Multics  process, the
operator  can  use  the  "reply"  command  to  send  it arbitrary

The access of this process  could be restricted.  A seperate gate
containing only the necessary entries for the dump side of backup
could be created,  or they could be added  to the volume dumper's
gate hc_backup_.  Instead of giving *.SysDaemon access to all the
branches in  the storage system,  the volume dumper  switches (or
new switches) could be used to control access via these entries.

The  volume dumper  already uses  a restricted  gate, and  is not
given access to the hierarchy in any extensive fashion.  However,
both the  volume dumper and  the hierarchy dumper  with the added
restrictions  discussed  above  would be  processes  with unusual
abilities  under the  complete control of  operations.  All other
such  processes run  in restricted environments  to add assurance
that the operators cannot exploit these abilities.

Running the dumper processes  in a restricted command environment
would  prevent   the  operators  from   exploiting  the  existing
abilities of the hierarchy dumper except via a flaw in the dumper
software.   This  MTB  proposes restricted  environments  for the
dumpers.   Future work  should examine  restricting the hierarchy
dumper process' access to the file system.

3_ R_E_L_O_A_D_E_R_S_ A_N_D_ R_E_T_R_I_E_V_E_R_S_

This MTB  does not discuss  reloaders and retrievers.   It is the
author's belief that these are inescapably privileged operations.
Even  the  retrieval  of  a  previous  version  of  a  segment or
directory can be a serious security  breach if it is done without
proper  authorization, since  it can modify  or destroy protected
information.  At a secure site, reloads and retrievals would only
be run by trusted people.

4_ T_H_E_ R_E_S_T_R_I_C_T_E_D_ E_N_V_I_R_O_N_M_E_N_T_S_

For  an  initial  implementation,  the  obvious  approach  is  to
construct a  process overseer that  calls an ssu_  subsystem that
contains the  dumper commands as "multics_requests,"  in the ssu_

Multics Technical Bulletin                                MTB-657
Backup Dumper Subsystems

sense.  This also  offers the opportunity to improve  the ease of
use of these commands by assigning them more obvious (and in some
cases, shorter) names.

There  are  two possible  approaches to  the construction  of the
subsystem.   The first  is to  construct a  single subsystem with
requests for both the hierarchy  and volume backup dumpers.  Such
a subsystem would look like:

          Subsystem_name:        backup_dumper
          Subsystem_ec_suffix:   ec
          Subsystem_prompt:      "Enter command (backup dumper)^/"



          begin_hierarchy_incremental  -> start_dump

          wakeup_hierarchy_incremental -> wakeup_dump

          end_hierarchy_incremental    -> end_dump

          hierarchy_catchup            -> catchup_dump

          hierarchy_complete           -> complete_dump

          begin_volume_incremental     -> incremental_volume_dump

          wakeup_volume_incremental ->    wakeup_volume_dump

MTB-657                                Multics Technical Bulletin
                                         Backup Dumper Subsystems

          end_volume_incremental    ->    end_volume_dump

          volume_catchup            ->    volume_catchup_dump

          volume_complete           ->    volume_complete_dump

The second alternative is to  create two subsystems, one for each
dumper.   Inside  each  subsystem,   the  markings  "volume"  and
"hierarchy"  would  be  omitted  from  the  request  names.   The
subsystem    names    would    be    "volume_backup_dumper"   and
"hierarchy_backup_dumper",         and         the        prompts
"Enter command (volume backup)"                               and
"Enter command (hierarchy backup)".   In all  cases, the exec_com
search list would be "backup_dumper".

Since any  given process should  only be running one  dumper at a
time, the two subsystem approach seems easiest on the users.

5_ I_M_P_L_E_M_E_N_T_A_T_I_O_N_ C_O_N_S_I_D_E_R_A_T_I_O_N_S_

An initial  implementation of both of  the subsystem alternatives
has been made.  This implementation  makes no changes to the code
of the dumpers.  They are called "as is."  This, or course, means
that any error messages that they produce continue to carry their
old names.   In addition, no  provision is made  for changing the
default or permissible control arguments for any of the commands.
A site might well want to insure that a particular set of control
arguments  were  always  used.   This  might  be  accomplished by
providing a "one-way" abbrev request; the start_up exec_com could
lock the  process in to  an abbrev profile  with suitable command
lines.  This  would require abbrev  to have an  option that would
expand abbreviations  while forbidding some or  all of the abbrev
control requests, such as ".u".  All  of this can be addressed in
a future version.

6_ A_ M_I_N_O_R_ E_X_T_E_N_S_I_O_N_ T_O_ S_S_U__

The ssu_  implementation of "standard  requests" in inappropriate
for  securely restricted  subsystems.  While a  subsystem can use
the  "unknown_request" macro  to disable a  standard request, the
implementor   has  no   guarantee  that   a  future   version  of

Multics Technical Bulletin                                MTB-657
Backup Dumper Subsystems

ssu_request_tables_$standard_requests will not add a request that
allows  the user  unwanted privilege.   Therefore, a  new request
table,   ssu_request_tables_$restricted_requests,  needs   to  be
added.  It contains all the the existing standard_requests except
for the "execute" request.

7_ D_E_B_U_G_G_I_N_G_ A_N_D_ A_D_M_I_N_I_S_T_R_A_T_I_O_N_

     Like the Initializer process, the dumper processes need some
escape mechanism by which  maintainers can reach ordinary command
level.  This  will be implemented  via an "admin"  request, which
will demand a assword.  This password will be stored in the PNT.
A  future  MTB on  PNT  management will  discuss  storing "admin"