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
1 ABSTRACT
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 INTRODUCTION
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
discretion.
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 RCP SECURITY POLICIES
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
3.2.1 RESOURCE MANAGEMENT DISABLED
| 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
3.2.2 RESOURCE MANAGEMENT ENABLED
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
| 3.4.1 SETTING POTENTIAL ACCESS CLASS RANGE AND ACCESS CLASS RANGE
| 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 DESIGN DISCUSSION REVIEW AND IMPLEMENTATION DETAILS
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
4.2.1 DESIGN DISCUSSION
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.
4.2.2 IMPLEMENTATION OF RCP_ACCESS_KERNEL_
| 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);
| 4.2.3 CHANGES TO OTHER MODULES
| 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
4.3.1 DESIGN DISCUSSION
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.
| 4.3.2 IMPLEMENTATION OF RCP_AUDIT
| 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
4.4.1 REGISTRY OPERATIONS
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.
4.4.2 CLEANUP HANDLERS
| 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.
4.4.3 PARAMETER PASSING
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
4.5.1.1 TR Details
Summary:
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.
4.5.1.2 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
release.
Multics Technical Bulletin MTB-682-01
Modifications to RCP
APPENDIX
MTB-682-01 Multics Technical Bulletin
Modifications to RCP
ACCESS_OPERATIONS_.ALM
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
RCP_OPS.INCL.PL1
/* 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
RCP_REQUESTOR_INFO.INCL.PL1
/* 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
RCP_RESOURCE_INFO.INCL.PL1
/* 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
ACCESS_AUDIT_RCP_INFO.INCL.PL1
/* 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);
dcl AUDIT_RCP_OBJ_INFO_VERSION_1
fixed bin (9) uns unal static options (constant) init (1);
/* END include file - access_audit_rcp_info.incl.pl1 */