MULTICS DESIGN DOCUMENT MDD-009 To: MDD Distribution From: Maria M. Pozzo Date: September 1, 1985 Subject: Resource Control Package Abstract: This MDD covers the management and internal organization of resources (devices and volumes) on Multics. Revisions: REVISION DATE AUTHOR initial 85-08-01 Maria M. Pozzo 01 85-09-01 Maria M. Pozzo _________________________________________________________________ Multics Design Documents are the official design descriptions of the Multics Trusted Computing Base. They are internal documents, which may be released outside of Multics System Development only with the approval of the Director. i MDD-009 Resource Control Package CONTENTS Page Section 1 Overview of the Resource Control Package 1-1 1.1 Services of RCP . . . . . . . . . 1-1 1.1.1 Functions of RCP Without RM Enabled . . . . . . . . . . . . . 1-2 1.1.2 Functions of RCP With RM Enabled . . . . . . . . . . . . . 1-3 Section 2 Security Issues in the Resource Control Package . . . . . . . . . . . . . . . . 2-1 2.1 Extended Access Modes for RCP . . 2-1 2.2 RCP Discretionary Access . . . . . 2-2 2.2.1 Resource Management Disabled 2-2 2.2.2 Resource Management Enabled . 2-2 2.3 Ring Brackets (Intraprocess Access Control) . . . . . . . . . . . . . . 2-2 2.4 AIM Restrictions (Mandatory Access Control) . . . . . . . . . . . . . . 2-2 2.4.1 Setting Potential Access Class Range and Access Class Range 2-3 2.4.2 Determination of AIM Access . 2-4 2.5 Gates, Privileges and Special Access . . . . . . . . . . . . . . . 2-4 2.6 Operations and Required Access . . 2-5 ii Resource Control Package MDD-009 SECTION 1 OVERVIEW OF THE RESOURCE CONTROL PACKAGE The Resource Control Package (RCP) controls the usage of and the access to I/O devices (tape drives, printers, punches, etc.) and physical volumes that can be mounted on these devices (tape volumes, forms, disk packs, etc.). RCP manages these resources through programs located in ring-1 and which run in the user's process. 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. 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. _1_._1 _S_E_R_V_I_C_E_S _O_F _R_C_P RCP software reserves, assigns and mounts resources; demounts, unassigns, and cancels resource reservations. The RM option of RCP manages registration and acquisition as well as deregistration and release of resources. The hierarchical level of these functions are: 1-1 MDD-009 Resource Control Package 1 register ---------| |-Resource Management 2 acquire ---------| 3 reserve ---------| | 4 assign | | 5 attach | |-Resource Control 5 detach | | 4 unassign | | 3 cancel ---------| 2 release ---------| |-Resource Management 1 deregister ---------| The following two subsections outline, and briefly describe, the functions provided by RCP with and without RM enabled. _1_._1_._1 _F_u_n_c_t_i_o_n_s _o_f _R_C_P _W_i_t_h_o_u_t _R_M _E_n_a_b_l_e_d 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 1-2 Resource Control Package MDD-009 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. _1_._1_._2 _F_u_n_c_t_i_o_n_s _o_f _R_C_P _W_i_t_h _R_M _E_n_a_b_l_e_d When RM is enabled by a site, 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 (see rcp_resource_types.incl.pl1). 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 (execute) 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. 1-3 MDD-009 Resource Control Package 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. 1-4 Resource Control Package MDD-009 SECTION 2 SECURITY ISSUES IN THE RESOURCE CONTROL PACKAGE The following subsections discuss the security policy of the Resource Control Package with and without Resource Management Enabled. _2_._1 _E_X_T_E_N_D_E_D _A_C_C_E_S_S _M_O_D_E_S _F_O_R _R_C_P 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 separately according to the access rules described in the following sections and is dependent upon Resource Management enabled or disabled. 2-1 MDD-009 Resource Control Package _2_._2 _R_C_P _D_I_S_C_R_E_T_I_O_N_A_R_Y _A_C_C_E_S_S _2_._2_._1 _R_e_s_o_u_r_c_e _M_a_n_a_g_e_m_e_n_t _D_i_s_a_b_l_e_d The raw mode is determined by looking at the ACS segment found in >sc1>rcp>RESOURCE_NAME.acs (i.e. tape_01.acs, dska_03.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 *.*.*. _2_._2_._2 _R_e_s_o_u_r_c_e _M_a_n_a_g_e_m_e_n_t _E_n_a_b_l_e_d 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 everyone owner = free NULL everyone owner = system NULL everyone _2_._3 _R_I_N_G _B_R_A_C_K_E_T_S _(_I_N_T_R_A_P_R_O_C_E_S_S _A_C_C_E_S_S _C_O_N_T_R_O_L_) 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. _2_._4 _A_I_M _R_E_S_T_R_I_C_T_I_O_N_S _(_M_A_N_D_A_T_O_R_Y _A_C_C_E_S_S _C_O_N_T_R_O_L_) 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 2-2 Resource Control Package MDD-009 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. _2_._4_._1 _S_e_t_t_i_n_g _P_o_t_e_n_t_i_a_l _A_c_c_e_s_s _C_l_a_s_s _R_a_n_g_e _a_n_d _A_c_c_e_s_s _C_l_a_s_s _R_a_n_g_e 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: ox The potential access class range specified must be a subset of the access class range specified in the RTDT. ox 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. ox The access class range specified must be a subset of the potential access class range. ox 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. 2-3 MDD-009 Resource Control Package _2_._4_._2 _D_e_t_e_r_m_i_n_a_t_i_o_n _o_f _A_I_M _A_c_c_e_s_s 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: ox 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. ox 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. ox 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. _2_._5 _G_A_T_E_S_, _P_R_I_V_I_L_E_G_E_S _A_N_D _S_P_E_C_I_A_L _A_C_C_E_S_S 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 register_resource which all require E access to rcp_admin_ gate; reconstruct_registry and remove_registry which require E access 2-4 Resource Control Package MDD-009 to rcp_sys_ gate. Other commands, such as acquire_resource require the use of the -priv argument to use the privileged 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. 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". 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. _2_._6 _O_P_E_R_A_T_I_O_N_S _A_N_D _R_E_Q_U_I_R_E_D _A_C_C_E_S_S 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. ox Register a resource requires E access to rcp_admin_ gate. ox Deregister a resource requires E access to rcp_admin_ gate. ox 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. ox Release a resource acquisition requires the user be the resource owner and have REW effective access to the resource. A user with E access to 2-5 MDD-009 Resource Control Package rcp_admin_ gate can force the release of a resource acquired to another user. ox Reserve a volume requires R effective access. ox Reserve a device requires RW effective access. ox 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. ox Assign a volume for reading requires R effective access. ox Assign a volume for writing requires RW effective access. ox Assign a device devices are always assigned for writing and require RW effective access. ox 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. ox Attach a resource same as for assignment. ox Detach a resource same as for unassign. ox Preload a volume requires R effective access. ox Preload a device requires RW effective access. ox Add or delete a device requires E access to rcp_sys_, and R access to the deivce. ox Set access_class_range or potential_access_class_range requires E access to rcp_admin_ gate and REW effective access to the resource. 2-6 Resource Control Package MDD-009 ox Set ACS path user must be the owner or requires E access to rcp_admin_ gate and requires REW effective access to the resource. ox Set comment field requires REW effective access to the resource. ox Set release_lock, lock, location or charge_type requires E access to rcp_admin_ gate and REW effective access to the resource. ox Get status of a resource requires R effective access. ----------------------------------------------------------- Historical Background This edition of the Multics software materials and documentation is provided and donated to Massachusetts Institute of Technology by Group BULL including BULL HN Information Systems Inc. as a contribution to computer science knowledge. This donation is made also to give evidence of the common contributions of Massachusetts Institute of Technology, Bell Laboratories, General Electric, Honeywell Information Systems Inc., Honeywell BULL Inc., Groupe BULL and BULL HN Information Systems Inc. to the development of this operating system. Multics development was initiated by Massachusetts Institute of Technology Project MAC (1963-1970), renamed the MIT Laboratory for Computer Science and Artificial Intelligence in the mid 1970s, under the leadership of Professor Fernando Jose Corbato. Users consider that Multics provided the best software architecture for managing computer hardware properly and for executing programs. Many subsequent operating systems incorporated Multics principles. Multics was distributed in 1975 to 2000 by Group Bull in Europe , and in the U.S. by Bull HN Information Systems Inc., as successor in interest by change in name only to Honeywell Bull Inc. and Honeywell Information Systems Inc. . ----------------------------------------------------------- Permission to use, copy, modify, and distribute these programs and their documentation for any purpose and without fee is hereby granted,provided that the below copyright notice and historical background appear in all copies and that both the copyright notice and historical background and this permission notice appear in supporting documentation, and that the names of MIT, HIS, BULL or BULL HN not be used in advertising or publicity pertaining to distribution of the programs without specific prior written permission. Copyright 1972 by Massachusetts Institute of Technology and Honeywell Information Systems Inc. Copyright 2006 by BULL HN Information Systems Inc. Copyright 2006 by Bull SAS All Rights Reserved