Multics Technical Bulletin                             MTB-682-01
  Modifications to RCP

  To:       Distribution

  From:     Maria M. Pozzo

  Date:     04/09/85

  Subject:  Modifications to RCP access controls - Revision 1


       The purposes  of this document are:   first, to clarify
       the conception that the  Resource Control Package (RCP)
       and  Resource  Management  (known  as  RCPRM)  are  two
       separate  entities;  second, to  state  in a  clear and
       concise manner the access control policies supported by
       RCP;  and last  to describe  the implementation  of the
       changes  made to  RCP to  meet the  design requirements
       stated in MTB-682.

  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.
     4 Cambridge Center
     Cambridge, Massachusetts 02139

  via telephone:
     (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-682-01                             Multics Technical Bulletin
                                               Modifications to RCP


  2.1 Resource Control Package

| The Resource Control Package (RCP)  controls the usage of and the
| access to I/O devices.  This  package allows users the ability to
| assign  devices  to  their  process.   The  result  of  a  device
| assignment grants users exclusive rights to that device until the
| process  teminates or  the device  is explicilty  unassigned.  In
| addition, users  can reserve a  set of one or  more resources for
| use at  some future time.   When an assignment  is requested, RCP
| will select a  device from the set already  reserved by the user.
| If  no devices  are reserved,  RCP will  assign a  device that is
| appropriate  according   to  criteria  specified   by  the  user,
| accessible to the user, and  available (where available means not
| deleted  and  not  in  use).  The  most  common  use  of resource
| reservations is by absentee_utility_.   An absentee job requiring
| some set of resources will not be started until absentee_utility_
| reserves  those  resources  thereby guaranteeing  success  of any
| resource  assignments or  attachments by the  absentee job.  Like
| assignments, reservations grant exclusive  rights to the resource
| until  the process  terminates or  the reservation  is explicitly
| cancelled.

  In  order to  actually use  a device, a  process must  own an IOI
  attachment  to  it.   To  allow  RCP  to  enforce  the assignment
  discipline,  users  are prohibited  from calling  ioi_$attach and
  ioi_$detach directly.  Instead, RCP provides a mechanism for both
  attaching and detaching to a  previously assigned device.  In the
  event that  a process attempts to  attach to a device  it has not
  yet assigned, RCP will  automatically accomplish this step.  When
  the process has  completed its use of the  device, it can detach,
  unassign and cancel its reservation.

| There  are  three  main  databases  of  RCP.   The  Resource Type
| Description  Table  (RTDT),  located in  >sc1>rtdt,  contains one
| entry (RTDE) for each resource type known to the system.  Another
| database,  found  in  >sl1>rcp_data,  contains  information about
| specific  devices  managed   by  RCP.   Lastly,  >sl1>rcp_com_seg
| contains   information   about   current   device   reservations,
| assignments  and  attachments.  The  RTDT  is an  installed table
| while rcp_data and rcp_com_seg are not retained across bootloads.

  2.2 Resource Control Package with Resource Management Enabled

| Resource  Management  (RM)  is  an  option  of  RCP  which allows
| enforcement of  mandatory access controls (AIM)  for all resource
| types, volumes as well as devices.  When RM is enabled by a site,

  Multics Technical Bulletin                             MTB-682-01
  Modifications to RCP

  resources are  introduced to the system  through the registration |
  process.  A registry is a database, one for each type of resource |
  in the RTDT, which consists of a set of records where each record
  identifies one  particular resource of that  type.  Each entry in
  the  RTDT,  (RTDE),  in  turn describes  the  associated registry
  located in >sc1>rcp>RESOURCE_TYPE.rcpr.  To  make a resource of a
  particular  type  available  to   the  system,  the  resource  is
  registered and the  information is kept in the  registry for that
  resource  type.  A  resource can  be registered  with information
  such as its name, owner, and potential access class range for AIM
  restrictions.   Registering a  resource has the  effect of making
  the resource part of the free  pool of resources available to the
  system.  A resource registered in  the free pool is available for
  acquisition by everyone.  Resources that are registered remain so
  until they are explicitly deregistered making them unavailable to
  the system.

  Once  a  resource  has  been  registered,  it  can  be  acquired.
  Resources are acquired from the free pool for use by a particular
  user.  The owner of the resource then becomes that user until the
  resource is  released.  When a resource  is released, the "manual
  clear"  flag  is checked.   If  it is  on,  the resource  must be
  cleared, with the clear_resource command, by a user with E access
  to the  rcp_sys_ gate.  Once  the resource is cleared,  or if the
  "manual  clear" flag  is off,  the resource  returns to  the free
  pool.   Often,  a site  will acquire  a set  of resources  to the
  system pool, thus making the  owner "system".  For example, it is
  recommended that tape  and disk drives be acquired  to the system
  pool for the common benefit of all to use.

  Enabling RM  provides a site  with an additional  option, that of
  auto  registration.  It  is possible for  a site to  turn on auto
  registration so that  when a process requests a  resource, and it
  has not been registered, it will be automatically registered.  It
  seems  unlikely,  however, that  a site  running with  RM enabled
  would  want  to  do this,  since  such  a site  is  probably more
  conscious  of  security  issues  and would  want  to  enforce the
  additional security features provided  by the manual registration |
  process of Resource Management.                                   |

  2.3 Conclusion

  As seen above, the Resource  Control Package works in tandem with
  Resource  Management  when the  later  is enabled.   Indeed, they
  should  not  be  thought  of as  two  separate  entities.   It is
  possible to have  RCP without RM enabled, but  it is not possible
  to have RM without RCP.   Resource Management is simply a feature
  of the Resource  Control Package that can be  enabled at a site's

  MTB-682-01                             Multics Technical Bulletin
                                               Modifications to RCP

  Section 3  of this document will  elaborate the security policies
  enforced  by  the  Resource  Control Package  both  with Resource
  Management  enabled  and disabled.   Section  4 will  discuss the
  implementation  of the  changes made  to RCP  to meet  the design
  requirements specificed in MTB-682.


  3.1 Extended Access Modes for RCP

  Although  the access  modes for RCP  objects are the  same as for
  segments, that being REW, they are actually extended access modes
  with a different meaning than the standard segment access modes.

        read (R)      - a process with R access to a resource
                        can read the contents of the resource.

        write (W)     - a process with W access to a resource can
                        write the contents of the resource.

        executive (E) - a process with E access to a resource can
                        change the attributes of the resource, in
                        effect giving the  same rights to  the
                        process as the resource owner would have.

  The three  types of access, discretionary  access (Access Control
  Lists), intraprocess access (ring brackets), and mandatory access
  (AIM),  are  used  in  combination  to  determine  the  real,  or
  effective,  access  mode of  the  process to  the  resource.  The
  effective   mode   is   determined  by   first   calculating  the
  discretionary access  or raw mode,  and performing a  logical AND
  with the ring  bracket mode.  Then performing a  logical AND with
  the  AIM  mode.  Each  type  of access  is  determined seperately
  according to the access rules described in the following sections
  and is dependent upon Resource Management enabled or disabled.

  3.2 RCP Discretionary Access


| The raw mode is determined by looking at the ACS segment found in
| >sc1>rcp>RESOURCE_NAME.acs.   There  will be  an ACS  segment for
| every device  known to RCP.   Volumes do not have  an ACS segment
| when Resource  Management is disabled.  The  default raw mode for
| volumes is RW for *.*.

  Multics Technical Bulletin                             MTB-682-01
  Modifications to RCP


  The appropriate  registry for the  type of resource  is found via
  the  RTDT.  It  is called  >sc1>rcp>RESOURCE_TYPE.rcpr.  Once the
  registry is  found, it is  searched for the  particular device or
  volume record.  The record specifies  the ACS pathname from which
  the raw mode is determined.  There  will always be an ACS segment |
  for devices, regardless of whether RM is disabled or enabled.  If |
  no ACS exists for a volume, the following defaults are used:      |

       owner = Person_id.Project_id  REW owner
                                     NULL world
       owner = free                  NULL world
       owner = system                NULL world

  3.3 Ring Brackets (Intraprocess Access Control)

  Ring  brackets  are  found  by   looking  at  the  ring  brackets
  associated with the ACS segment  for the resource.  The rules for
  locating the ACS segment are dependent on whether or not Resource
  Management is enabled and is the same as for Discretionary Access
  (see above).  In the event that there is no ACS segment, the ring
  bracket check is bypassed.

  In the event that ring brackets  do exist, the resource will have
  ring brackets in  the form of r1,r2,r3 as  segments do.  However,
  the implementation is different than  the normal handling of ring
  brackets.   0-r1 defines  the REW  (read/executive/write) bracket
  while 0-r2 defines the R (read) bracket.

  3.4 AIM Restrictions (Mandatory Access Control)

  Since AIM  restrictions are not imposed  when Resource Management
  is disabled, this discussion only  applies to when RM is enabled.
  Each resource has a range associated  with it known as the access
  class  range  of the  resource  and is  used  to determine  how a
  process can  access a resource subject  to AIM restrictions.  The
  range is  in the form  of min_access_class:max_access_class where
  min <= max.  Each access class has the form of level and category
  set where the category set can be null.

  MTB-682-01                             Multics Technical Bulletin
                                               Modifications to RCP


| A  user  must have  E  access to  rcp_admin_  gate to  register a
| resource.   When  a  resource  is  registered  it  is  assigned a
| potential access class range.  The default potential access class
| range is taken from the RTDT  access class range for that type of
| resource.  If  the potential access  class range is  specified in
| the registration process, the following rules apply:

|      1.  The potential  access class  range  specified  must be a
|          subset of the access class range specified in the RTDT.

|      2.  The min_access_class of the potential access class range
|          specified  cannot  be  less  than  the  user's   current
|          authorization unless the rcp privilege is turned on.

| When  a resource  is acquired,  it is  assigned an  actual access
| class   range.     The   default   is    minimum_access_class   =
| maximum_access_class = process' current authorization, which is a
| single-class resource.   A user with E  access to rcp_admin_ gate
| can specify an access class  range at acquisition time subject to
| the rules specified below.

|      1.  The access class range specified must be a subset of the
|          potential access class range.

|      2.  The min_access_class of the specified access class range
|          cannot  be  less  than the  user's current authorization
|          unless the rcp privilege is turned on.

| It  should be  noted that a  volume with  a min_access_class less
| than  the   max_access_class  is  a   multi-class  volume.   Only
| processes running  in ring-1 or processes  with the rcp privilege
| turned  on  will  be  allowed to  assign  and  attach mutli-class
| volumes.  However, there is  currently no supporting software for
| accessing multi-class  volumes.  A device, on  the other hand, is
| often acquired as  a multi-class resource but at  attach time the
| access       class       range      becomes       the      user's
| current_authorization:current_authorization     and     thus    a
| single-class resource.

  Multics Technical Bulletin                             MTB-682-01
  Modifications to RCP

  3.4.2 DETERMINATION OF AIM ACCESS                                 |

  If the resource is free (i.e.  owner = "free"), the AIM access is |
  determined from  the potential access class  range and the user's |
  current  authorization;  otherwise the  AIM access  is determined |
  from the access class range and the user's current authorization. |
  Access is determined according to the following rules and order:  |

       *  If  the min_access_class is greater than or disjoint from |
          the user's  current authorization, R access (and thus all |
          access) is denied since we can't read up.                 |

       *  Since E access  allows  writing  of protected attributes, |
          the  user's  current  authorization must  be equal to the |
          min_access_class.  E access is denied  anywhere  else  in |
          the range to prevent a potential covert channel.          |

       *  If  the  max_access_class  is  less than  or  disjoint, W |
          access  is denied since we can't write down.  R access is |
          preserved,  however, E  access  must also be denied since |
          that allows writing  of protected  attributes and we have |
          just been denied W access.                                |

  3.5 Gates, Privileges and Special Access                          |

  There  are  four  main  gates through  which  RCP  operations are |
  performed.   The  ring  brackets  on all  four  gates  are 1,1,5. |
  Normal user  commands such as  acquire_resource, assign_resource, |
  attach_,  detach_, list_resource,  etc., use the  rcp_ gate.  The |
  ACL  on this  gate gives RE  access to *.*.   The rcp_admin_ gate |
  gives RE access to RCP administrators and system processes and is |
  generally   used   for    operations   such   as   copy_registry, |
  delete_registry,  register_resource_,  deregister_resource_, etc. |
  Access to the rcp_priv_ gate  is given only to special privileged |
  processes.   It  is primarily  used  for T&D  operations  such as |
  copy_meters,  and to  perform privileged  attaches.  The rcp_sys_ |
  gate  gives access  only to  system daemon  processes and special |
  system  processes.  Operations  called through  rcp_sys_ are used |
  primarily   during   system   initialization   and   creation  or |
  re-creation  of the  RCP registries.   Operator commands  such as |
  clear_resource and authenticate_device, as well as add and delete |
  device are also called through rcp_sys_.                          |

  There are two  kinds of privilege.  The first  is privileged gate |
  access.  For RCP  purposes, a user with E  access to rcp_sys_, or |
  rcp_admin_ has privileged gate access.   The use of some commands |
  require   privileged   gate  access.    Examples  of   these  are |
  copy_registry,    delete_registry,     deregister_resource    and |

  MTB-682-01                             Multics Technical Bulletin
                                               Modifications to RCP

| register_resource which all require  E access to rcp_admin_ gate;
| reconstruct_registry and  remove_registry which require  E access
| to  rcp_sys_  gate.   Other  commands,  such  as acquire_resource
| require the use of the -priv  argument to use the privileged gate
| acquire_resource as opposed to the regular acquire_resource.  The
| Commands  and  Active  Functions  Manaul  (AG92)  specifies these
| control arguments.  Performing an  operation through a privileged
| gate (rcp_sys_  or rcp_admin_), has the  effect of by-passing the
| access checks  for discretionary access (ACL  and ring brackets),
| but not  AIM checks.  For  RCP purposes, access  to the rcp_priv_
| gate is not considered privileged  gate access in that performing
| an  operation  through rcp_priv_  does not  by-pass discretionary
| access checks.

| The second  type of privilege  is the rcp  system privilege.  The
| user must have  the ability to set system  privileges in order to
| turn on the rcp privilege.  Turning  on the rcp privilege has the
| effect  of   by-passing  the  AIM  access   checks  but  not  the
| discretionary access checks.

| Special   privilege   is   granted   to  Initializer.SysDaemon.z,
| by-passing all access checks  and automatically given REW access.
| This occurs  mainly during system  boot when RCP  is initialized.
| In addition, the effective mode is  REW for a register or acquire
| operation.  The only access checks made for a register or acquire
| operation are those listed  above under "Setting Potential Access
| Class Range and Access Class Range".

| 3.6 Operations and Required Access

| Some  operations require  different effective  access for volumes
| and devices.  Other operations  are independent of resource type.
| The following  list identifies the  types of RCP  operations, the
| required  effective  access  and  any  other  access requirements
| needed to perform the operation.

|      Register a resource - requires E access to rcp_admin_ gate.

|      Deregister  a  resource -  requires  E access  to rcp_admin_
|      gate.

|      Acquire a resource - requires E access to rcp_admin_ gate to
|      acquire a resource for someone else.  Everyone has access to
|      acquire  all other  resources for  themselves.  The resource
|      must have an owner = "free" to be acquired.

|      Release a  resource acquisition -  requires the user  be the
|      resource  owner  and  have   REW  effective  access  to  the

  Multics Technical Bulletin                             MTB-682-01
  Modifications to RCP

       resource.  A user with E access to rcp_admin_ gate can force |
       the release of a resource acquired to another user.          |

       Reserve a volume - requires R effective access.              |

       Reserve a device - requires RW effective access.             |

       Cancel a resource reservation -  requires the user to be the |
       one who made  the volume reservation.  A user  with E access |
       to rcp_sys_  gate can cancel  a reservation made  by another |
       user.  Does not require any access to the resource.          |

       Assign a volume for reading - requires R effective access.   |

       Assign a volume for writing - requires RW effective access.  |

       Assign a  device - devices  are always assigned  for writing |
       and require RW effective access.                             |

       Unassign a  resource - requires  the user to be  the one who |
       made  the  resource assignment.   A  user with  E  access to |
       rcp_admin_ gate  can force an unassignment.   In addition, a |
       process   termination   forces  the   unassignment   of  all |
       acquisitions for the process.                                |

       Attach a resource - same as for assignment.                  |

       Detach a resource - same as for unassign.                    |

       Preload a volume - requires R effective access.              |

       Preload a device - requires RW effective access.             |

       Add or delete a device - requires E acces to rcp_sys_, and R |
       access to the deivce.                                        |

       Set  access_class_range  or  potential_access_class_range  - |
       requires  E  access  to  rcp_admin_ gate  and  REW effective |
       access to the resource.                                      |

       Set ACS path  - user must be the owner  or requires E access |
       to rcp_admin_ gate and requires  REW effective access to the |
       resource.                                                    |

       Set  comment field  - requires  REW effective  access to the |
       resource.                                                    |

       Set release_lock, lock, location  or charge_type - require E |
       access to  rcp_admin_ gate and  REW effective access  to the |

  MTB-682-01                             Multics Technical Bulletin
                                               Modifications to RCP

|      resource.

|      Status a resource - requires R effective access.


  4.1 Introduction

  There are several areas in RCP  where changes were made.  Each of
  the  following  sections reviews  the  design proposal  stated in
  MTB-682 for each of the areas where changes were made.  The first
  area is that  of access control.  An access  control "kernel" for
  RCP  was  implemented  such  that  all  access  computations  and
  decisions are determined in one  place.  Section 4.2 outlines the
  design and detailes the implementaiton.   The second area is that
  of auditing.  RCP previously did no useful auditing.  Section 4.3
  discusses  the  implementation of  the new  RCP auditing  and the
  interface  to the  Ring-1 audit  mechanism.  The  evaluation team
  reported a  number of parameter passing  problems with the entire
  subsystem.  Section 4.3 details these items.  Lastly, Section 4.4
  details the fix for TR17466.

  4.2 Access Control Kernel for RCP


  The kernel,  called rcp_access_kernel_, is called  for all access
  computations  and  checks  made throughout  this  subsystem.  The
  "kernel"  asks the  question "Is RM  turned on?".   If so, access
  checks are made  by asking for registry information  or using the
  approporiate defaults; if not access is computed or checked using
  regular methods as described in Section 3 above.


| The interface to rcp_access_kernel_ is as follows:

|     declare rcp_access_kernel_ entry (bit (36) aligned, ptr, ptr,
|                                       bit (3), fixed bin (35));

|     rcp_access_kernel_: proc (operation, requestor_info_ptr,
|                               resource_info_ptr, effmode,
|                               code);

  Multics Technical Bulletin                             MTB-682-01
  Modifications to RCP

  The follwing list describes variables  input, output and local to |
  rcp_access_kernel_.                                               |

  operation (input):                                                |

       The first  18 bits of  the RCP operation  are implemented in |
       the    same    manner   as    the   operations    found   in |
       access_operations_.alm used for  ring-0 and ring-1 auditing. |
       For  example,  an  assign  for  reading  operation  would be |
       access_operations_$rcp_assign_read.    A   list   of   these |
       operations can  be found in  the appendix to  this document. |
       The second 18  bits of the RCP operation  are defined by the |
       include file rcp_ops.incl.pl1 which can also be found in the |
       appendix  to this  document.  This include  file defines the |
       details  of  the  operations   such  as  what  options  were |
       requested  on the  command line;  whether the  call was made |
       through  one  of  the  privileged  rcp  gates  (rcp_sys_  or |
       rcp_admin_); if the resource owner was the requestor of this |
       operation, etc.                                              |

  requestor_info_ptr (input):                                       |

       This variable points to information about the subject making |
       the request to RCP, or on  whose behalf the request is being |
       made.       The      structure       is      defined      in |
       rcp_requestor_info.incl.pl1   and   contains   the  user_id, |
       current_authorization   and   validation_level.    See   the |
       appendix for the detailes of this include file.              |

  resource_info_ptr (input):                                        |

       This  variable points  to a  stucture containing information |
       about   the   object.    The   structure   is   defined   in |
       rcp_resource_info.incl.pl1  and includes  the resource_name, |
       resource_type,  and,  if  RM is  enabled,  the registry_dir, |
       registry_record_pointer  and  registry_switch_ptr.   See the |
       appendix for details of this include file.                   |

  effmode (output):                                                 |

       This variable  is the effective  mode of the  process to the |
       resource and is detemined by rcp_access_kernel_.             |

  code (output):                                                    |

       This  variable  reflects  any  errors  during  processing of |
       rcp_access_kernel_.   It is  also used to  determine if this |
       was a DENY  or GRANT operation for auditing  purposes and is |
       printed in the audit message in the syserr log.              |

  MTB-682-01                             Multics Technical Bulletin
                                               Modifications to RCP

| The following psuedo-program describes the general implementation
| of rcp_access_kernel_.

|      rcp_access_kernel_: proc (operation, req_info_ptr,
|                                res_info_ptr, effmode, code);

|          call rcp_access_kernel_setup ({...});
|          if error_code ^= 0 then return;
|          if effmode ^= ""b then goto AUDIT;
|          if ^privileged_gate_call then do;
|             call rcp_compute_raw_mode ({...});
|             if acs_path ^= "" then do;
|                call rcp_compute_bracket_mode ({...});
|                call rcp_merge_modes ({...});
|             end;
|             else temp_effmode = raw_mode;
|          end;
|          if (rm_on & ^rcp_priv) then do;
|              call rcp_compute_aim_mode ({...});
|              call rcp_merge_modes ({...})
|          end;
|          else effmode = temp_effmode;
|          call rcp_operation_access ({...});

|          AUDIT:
|              call rcp_audit ({...});
|          return;
|      end rcp_access_kernel_;

| rcp_access_kernel_setup:

|      This  routine  will determine  if RM  is turned  on; perform
|      initialization   such   as   granting   default   access  to
|      Initializer.SysDaemon.z and default  access for register and
|      acquire   operations;  determine   the  ACS   pathname;  and
|      determine the owner.

|      dcl rcp_access_kernel_setup entry (bit (36) aligned, ptr, ptr,
|                                         bit (1), char (*),
|                                         bit (1), char (*),
|                                         bit (3), fixed bin (35));
|      rcp_access_kernel_setup: proc (operation, req_info_ptr,
|                                     res_info_ptr, rm_on,
|                                     acs_path, rcp_priv,
|                                     owner, effmode,
|                                     error_code);

  Multics Technical Bulletin                             MTB-682-01
  Modifications to RCP

  rcp_compute_raw_mode:                                             |

       This routine will determine the discretionary access for the |
       process  to the  resource.  Access is  determined as defined |
       above.                                                       |

       dcl rcp_compute_raw_mode entry (bit (1), ptr,                |
                                       char (*), char (*),          |
                                       bit (3),                     |
                                       fixed bin (35));             |
       rcp_compute_raw_mode: proc (rm_on, res_info_ptr,             |
                                   req_info_ptr, acs_path,          |
                                   owner, raw_mode,                 |
                                   error_code);                     |

  rcp_compute_bracket_mode:                                         |

       This   routine  will   determine  the   intraprocess  access |
       dependent on the ring brackets of the ACS segment.  If there |
       is no ACS segment, this check is by-passed.                  |

       dcl rcp_compute_bracket_mode entry (char (*), ptr, ptr,      |
                                           bit (3), (2) fixed bin (3)|,
                                           fixed bin (35));         |
       rcp_compute_bracket_mode: proc (acs_path, req_info_ptr,      |
                                       res_info_ptr, bracket_mode,  |
                                       rbs, error_code);            |

  rcp_merge_modes:                                                  |

       Given two access modes, this  routine will perform a logical |
       AND to determine the resultant merged mode.                  |

       dcl rcp_merge_modes entry (bit (3), bit (3),                 |
                                  fixed bin (35))                   |
                                  returns (bit (3));                |
       rcp_merge_modes: proc (mode1, mode2, error_code)             |
                                  returns (bit (3));                |

  MTB-682-01                             Multics Technical Bulletin
                                               Modifications to RCP

| rcp_compute_aim_mode:

|      This routine  has a main  entry point used  to determine the
|      AIM   access   of   the   subject   to   the   object.   The
|      permissible_aim  entry   point  is  used   for  setting  the
|      potential  access  class  range  and access  class  range as
|      described  above.  The  main entry point  is called directly
|      from  rcp_access_kernel_  and  is  used  in  determining the
|      effective  mode  as  described  above.   The permissible_aim
|      entry point is not called from within rcp_access_kernel_ but
|      is called  during a register, acquire  or set operation from
|      rcprm_find_resource_.

|      dcl rcp_compute_aim_mode entry (ptr, ptr, bit (3),
|                                      fixed bin (35));

|      rcp_compute_aim_mode: proc (req_info_ptr, res_info_ptr,
|                                  aim_mode, error_code);

|      dcl rcp_compute_aim_mode$permissible_aim entry
|                                ((2) bit (72) aligned,
|                                 (2) bit (72) aligned,
|                                 fixed bin (35));
|      permissible_aim: entry (max_range, aim_range,
|                              error_code);

| rcp_operation_access:

|      Given the effective mode of  the subject to the object, this
|      routine will determine if there  is enough access to perform
|      the desired operation.  The  effective mode required for the
|      various RCP operations is described above.

|      dcl rcp_operation_access entry (bit (36) aligned, char (*),
|                                      bit (1), bit (3),
|                                      fixed bin (35));
|      rcp_compute_bracket_mode: proc (operation, resource_type,
|                                      rm_on, effmode, error_code);


| Many modules in  RCP had to be changed to  interface with the new
| access  kernel.   Those  include  rcp_preload_  which  now  calls
| rcp_access_kernel_.   Previously,  only  access  on  devices  was
| checked prior to a preload.   Currently, if RM is enabled, access
| to the volume is also checked.   It is necessary, when using this
| command,  to  supply the  -user  argument since  defaults  are no
| longer used.

  Multics Technical Bulletin                             MTB-682-01
  Modifications to RCP

  Formerly all modules, with  the exception of rcp_reserve_, called |
  directly into  rcp_check_access_ allowing it to  make the call to |
  rcprm_access_control_  if RM  was enabled.   With the  new access |
  kernel, the call is made directly  to the access kernel where all |
  access checks are made.  Modules that fall into this category are |
  rcp_initializer_   (now    rcp_control_   -   see    below)   and |
  rcprm_find_resource_.                                             |

  Currently,  rcp_reserve_  calls rcprm_find_resource_  which calls |
  rcp_access_kernel_  to  perform  access checks.   This  module no |
  longer calls rcp_access_control_.                                 |

  The   new   access    kernel   replaces   rcp_check_access_   and |
  rcprm_access_control_  entirely.  They  will be  removed from the |
  system.                                                           |

  4.2.4 TESTING                                                     |

  Testing of the new access kernel was done on the CISL development |
  machine with RM enabled, and  with RM disabled.  Initially, these |
  tests were run manually but will be used as input for creation of |
  automated tests that will conform to  the standards set up by the |
  B2 evaluation team for functional testing.                        |

  In  addition,  a new  system  was created  from scratch,  and the |
  process of turning on RM for the first time was tested.           |

  4.3 RCP Auditing


  As part  of the B2  effort, a general  purpose auditing mechanism |
  was  created for  ring-0 and  ring-1 auditing.   (See MTB-679 and |
  MTB-692).   To  perform  RCP  auditing,  a  routine  was created, |
  rcp_audit, to interface with the ring-1 auditing mechanism.       |

  The first 18 bits of the  RCP operation conforms to the operation |
  format   required  by   the  ring-1   auditing  mechanism.   (See |
  access_operations_.alm in  the appendix).  The  rcp_audit routine |
  first determines  if auditing is  required at the  highest level. |
  If RM is  disabled, auditing is not done.   In addition, included |
  in the second 18 bits of the  RCP operation are a series of flags |
  that specify details of the operation.  One of those flags is the |
  search flag.  The search flag indicates if this operation is just |
  searching for an appropriate,  available and accessible resource. |
  For example, if the user  has requested a resource by attributes, |
  as opposed  to by name or  uid, then RCP will  be searching for a |

  MTB-682-01                             Multics Technical Bulletin
                                               Modifications to RCP

| device that meets the attribute specifications.  Searching is not
| considered  an auditible  event.  Once  a particular  resource is
| selected, the event is audited.

| In    general,   auditing    is   performed    directly   through
| rcp_access_kernel_ which  calls rcp_audit after  the access check
| has been made.  There are instances,  as in the case of searching
| as  stated  above, where  auditing is  performed elswhere  in the
| subsystem.   When  dealing  directly  with  the  registries,  for
| example, the creation of a new RCP object (a register operation),
| the ring-1  auditing routines are called  directly since there is
| no  object to  deal with  from the  point of  view of  the access
| kernel.


| The interface to rcp_audit is as follows:

|     declare rcp_audit entry (char (*), bit (36) aligned, ptr, ptr,
|                              char (*), bit (3), bit (3),
|                              (2) fixed bin (3), bit (1),
|                              fixed bin (35));

|     rcp_audit: proc (caller, operation, requestor_info_ptr,
|                      resource_info_ptr, owner, effmode, raw_mode,
|                      rbs, rm_on, error_code)
| The following psuedo-program describes the general implementation
| of rcp_audit.

|      rcp_audit: proc (...);

|          if ^rm_on | search_operation then return;
|          call rcp_setup_event ({...});
|          call hcs_$get_access_class ({...});
|          audit = access_audit_r1_$check_obj_class_range ({...});
|          if audit then do;
|             call get_obj_name ();
|             call fill_audit_record ();
|             call get_msg_str ();
|             call access_audit_r1_$log_obj_class_range ({...});
|          end;
|          return;
|      end rcp_audit;

  Multics Technical Bulletin                             MTB-682-01
  Modifications to RCP

  rcp_setup_event:                                                  |

       This routine sets up the  event flags required by the ring-1 |
       audit routines.   The event flags  are set based  on the RCP |
       operation.  The format  for the event flags can  be found in |
       access_audit_eventflags.incl.pl1.                            |

       dcl rcp_setup_event entry (bit (36) aligned, bit (3),        |
                                  bit (36) aligned, fixed bin (35));|
       rcp_setup_event: proc (operation, effmode, event_flag,       |
                              error_code);                          |

  get_obj_name:                                                     |

       This routine is  internal to rcp_audit.  It sets  up the RCP |
       object type and  name that will appear in  the audit message |
       in the syserr log.                                           |

  fill_audit_record:                                                |

       This routine is internal to  rcp_audit.  It fills in the RCP |
       audit record  used for printing information  about the event |
       in the audit  message in the syserr log.   The format of the |
       RCP      audit      record     can      be      found     in |
       access_audit_rcp_info.incl.pl1  in  the   appendix  to  this |
       document.                                                    |

  get_msg_str:                                                      |

       This  routine  is  internal  to rcp_audit.   It  is  used to |
       prepare  the  message string  that  is used  as part  of the |
       information printed  out in the audit  message in the syserr |
       log.                                                         |

  4.3.3 TESTING                                                     |

  Much  of  this   will  be  tested  within  the   test  cases  for |
  rcp_access_kernel_.   Checks  will  be  made to  insure  that the |
  correct message is being constructed and the right operations are |
  being audited.                                                    |

  4.4 General Cleanup


  There  were  several  programs  with  knowledge  of  the internal |
  structure of the registries embedded within them.  To cut down on |

  MTB-682-01                             Multics Technical Bulletin
                                               Modifications to RCP

| potential future problems, as much  of this knowledge as possible
| was  centralized  in  the new  program  rcprm_registry_util_.  An
| include file, rcprm_registry_keys.incl.pl1, was written to embody
| knowledge  of  the  key  formats  used  in  the  registries.  The
| programs which previously made use of their knowledge of registry
| formats were changed to use these new mechanisms.


| RCP code was  in general somewhat sloppy with  regard to cleaning
| itself up.   As modules were changed,  careful attention was paid
| to  the  cleanup  handlers  therein.   Any  module  that  did any
| allocations,  lockings,  attachments,  openings,  or  changing of
| validation  levels was  scrutinized, and  proper cleanup handlers
| were coded.


  Lastly,   during   penetration  testing,   the   evaluation  team
  identified a number  of areas in RCP where  parameter passing was
  handled incorrectly.  This information was documented by the team
| and indicates each module where a problem existed.  These modules
| are    rcprm_find_resource_,    rcp_assign_device,    rcp_attach,
| rcp_attach_lv_,        rcp_check_assign,       rcp_check_attach_,
| rcp_detach_lv_,         rcp_reserve_,        rcprm_registry_mgr_,
| rcprm_list_resource_,    rcp_mount_timer_,    rcp_preload_,   and
| rcprm_journalize_.  In all cases,  the parameter passing problems
| were corrected.

  4.5 Outstanding TRs

  4.5.1 TR PHX17466

  This TR is  fixed for MR11.  The following  sections describe the
  TR and the solution.

  Multics Technical Bulletin                             MTB-682-01
  Modifications to RCP TR Details


       copy_registry only works when the components in the registry
       are  numbered sequentially.   During normal  operation it is
       possible  for  a whole  segment  of the  registry msf  to be
       garbage collected.

  A  registry is  considered valid  by RCP  if one  of its internal
  components  does  not contain  any  information since  it  is not
  referenced by RCP.  For example,  if components 0,1 and 3 contain
  valid  information and  component 2  is missing,  the registry is
  considered valid.

  There  are  two  problems:   1) rcprm_registry_mgr_$copy_registry
  copies only the components prior  to the missing component and 2)
  does not notify the caller  of copy_registry that component 2 was
  missing or subsequent components were not copied. Solution

  Prior to  copying any components,  retrieve the bit_count  of the |
  msf which will indicate the number of components to copy.  A call |
  to hcs_$status_minf  will return the actual  bit_count of the msf |
  regardless of the missing  component.  For example, the bit_count |
  returned in the example above would  be 4 even though component 2 |
  is  missing.   The  call   to  msf_manager_$get_ptr  will  return |
  error_table_$noentry  if the  component is  missing from  the old |
  registry.  The component number is  saved and a null component is |
  created in the new registry.  An error message is returned to the |
  user  indicating which  component(s) were  missing and  that null |
  components were created in the new registry.                      |

  4.5.2 OTHER TRS

  A host of  outstanding TRs for RCP were  fixed for MR11.  MTB-682
  identifies several  that were candidates for  resolution for this

  Multics Technical Bulletin                             MTB-682-01
  Modifications to RCP


  MTB-682-01                             Multics Technical Bulletin
                                               Modifications to RCP


  The  portion   of  access_operations_.alm  which   refer  to  RCP
  operations is defined below:

  operation rcp_register,RCP,MODIFY,  (creation of rcp object)
  operation rcp_deregister,RCP,MODIFY,(deletion of rcp object)
  operation rcp_register_acquire,RCP,MODIFY_ACCESS,
                      (creation and acquisition of rcp object)
  operation rcp_acquire,RCP,MODIFY_ACCESS,
                      (acquisition of rcp object)
  operation rcp_release,RCP,MODIFY_ACCESS,
                      (release rcp object acquisition)
  operation rcp_reserve,RCP,READ,(reservation of rcp object)
  operation rcp_cancel,RCP,READ,(cancel rcp object reservation)
  operation rcp_preload,RCP,READ,(preload of rcp object)
  operation rcp_unload,RCP,READ,(unload of resource)
  operation rcp_assign_read,RCP,READ,(assign device for reading)
  operation rcp_assign_write,RCP,MODIFY,(assign device for writing)
  operation rcp_unassign,RCP,READ,(unassignment of rcp object)
  operation rcp_status,RCP,READ,(status of rcp object)
  operation rcp_set,RCP,MODIFY,(modify rcp object atributes)
  operation rcp_set_access,RCP,MODIFY_ACCESS,
                      (modify rcp object access attributes)
  operation rcp_clear,RCP,MODIFY,(manual clear rcp object contents)
  operation rcp_add_device,RCP,MODIFY,(creation of rcp object)
  operation rcp_delete_device,RCP,MODIFY,(deletion of rcp object)
  operation rcp_copy_registry,RCP,MODIFY,(creation of rcp registry)
  operation rcp_delete_registry,RCP,MODIFY,(deletion of registry)
  operation rcp_reconstruct_registry,RCP,MODIFY,
                      (reconstruction of rcp registry)
  operation rcp_update_registry_header,RCP,MODIFY,
                      (modification of rcp registry)
  operation rcp_copy_info,RCP,READ,(copy rcp meters or rcp data)
  operation rcp_error_count,RCP,READ,(read the rcp error count)
  operation rcp_account,RCP,READ,(read rcp accounting info)

  Multics Technical Bulletin                             MTB-682-01
  Modifications to RCP


  /*  BEGIN include rcp_ops.incl.pl1  */

  dcl       ops_ptr                ptr;

  dcl       1 detailed_operation   unaligned based (ops_ptr),
              2 given,
                3 potential_attributes
                                   bit (1),
                3 desired_attributes
                                   bit (1),
                3 potential_aim_range
                                   bit (1),
                3 aim_range        bit (1),
                3 owner            bit (1),
                3 acs_path         bit (1),
                3 location         bit (1),
                3 comment          bit (1),
                3 charge_type      bit (1),
                3 usage_lock       bit (1),
                3 release_lock     bit (1),
                3 user_alloc       bit (1),
              2 priv_gate_call     bit (1),
              2 search             bit (1),
              2 force              bit (1),
              2 process            bit (1),
              2 owner              bit (1),
              2 pad                bit (1);

  /* END include file rcp_ops.incl.pl1 */

  MTB-682-01                             Multics Technical Bulletin
                                               Modifications to RCP


  /*       BEGIN include file rcp_requestor_info.incl.pl1
   *       This include file gives information about the subject,
   *       or requestor of the RCP operation.  In one case, absentee
   *       requests, the user is the Initializer, so this piece of
   *       information tells us about the real requestor of the RCP
   *       operation.

  dcl requestor_info_ptr ptr;

  dcl 1 requestor_info aligned based (requestor_info_ptr),
      2 user_id char (32),
      2 current_authorization bit (72) aligned,
      2 validation_level fixed bin (3);

  /*  END include file .. rcp_requestor_info.incl.pl1 */

  Multics Technical Bulletin                             MTB-682-01
  Modifications to RCP


  /*       BEGIN include file rcp_resource_info.incl.pl1
     *       This include file gives information about the object,
     *       or resource for the RCP operation.  If RM is enabled this
     *       information will provide the registry name and switch pointer
     *       for the registry so additional resource information can be
     *       determined.

  dcl  resource_info_ptr   ptr;

  dcl  1 resource_info       based (resource_info_ptr),
       2 registry_dir        aligned char (64),
       2 registry_switch_ptr ptr,
       2 registry_record_ptr ptr,
       2 resource_type       char (32),
       2 resource_name       char (32);

  /*  END include file .. rcp_resource_info.incl.pl1 */

  MTB-682-01                             Multics Technical Bulletin
                                               Modifications to RCP


  /* BEGIN include file - access_audit_rcp_info.incl.pl1 */

  dcl audit_rcp_obj_ptr    pointer;

  dcl 1 rcp_obj_info      aligned based (audit_rcp_obj_ptr),
      2 info_type         fixed bin (9) uns unal,
      2 version           fixed bin (9) uns unal,
      2 pad               bit (18) unal,
      2 resource_type     char (32),
      2 resource_name     char (32),
      2 owner_id          char (32),
      2 flags,
        3 device          bit (1) unal,
        3 volume          bit (1) unal,
        3 registry        bit (1) unal,
        3 usage_locked    bit (1) unal,
        3 release_locked  bit (1) unal,
        3 awaiting_clear  bit (1) unal,
        3 has_acs_path    bit (1) unal,
        3 pad             bit (29) unal,
      2 attributes        (2) bit (72),
      2 access_class      (2) bit (72),
      2 raw_mode          bit (3),
      2 rcp_ring_brackets (2) fixed bin (3);

      fixed bin (9) uns unal static options (constant) init (1);

  /* END include file - access_audit_rcp_info.incl.pl1 */