Multics Technical Bulletin MTB-657 Backup Dumper Subsystems To: Distribution From: Benson I.Margulies Date: 05/11/84 Subject: Limited Subsystems for the Hierarchy and Volume Backup Dumpers 1_ A_B_S_T_R_A_C_T_ It should not be neccessary to trust Multics operators as System Security Adminstrators. However, the current interface to the hierarchy and volume dumpers allows the operator unrestricted use of a process with access to privileged gates. A malicious operator, using the Backup.SysDaemon process, can arbitrarily and invisibly subvert system security. This MTB describes a limited subsystem for the volume and hierarchy backup processes that eliminates this risk. This MTB proposes two options for the command repetoire of the subsystem. When a consensus is reached a revision will be issued describing only the definitive design. Comments should be sent to the author: via Multics Mail: Margulies at either System-M, MIT, or CISL-SERVICE. via Forum: >udd>m>mtgs>B2.forum on System-M via telephone: (HVN) 261-9333, or (617) 492-9333 _________________________________________________________________ Multics project internal working documentation. Not to be reproduced or distributed outside the Multics project without the consent of the author or the author's management. MTB-657 Multics Technical Bulletin Backup Dumper Subsystems 2_ I_N_T_R_O_D_U_C_T_I_O_N_ -_-_ T_H_E_ D_U_M_P_E_R_S_ Both the hierarchy and volume backup dumper processes introduce unacceptable security flaws in an operating Multics system. They are examined here in turn. The hierarchy dumper requires considerable access to do its work. It depends on access to hphcs_ and ACL access to all objects to be dumped, and runs in ring 1. Since it runs in an ordinary Multics process, the operator can use the "reply" command to send it arbitrary commands. The access of this process could be restricted. A seperate gate containing only the necessary entries for the dump side of backup could be created, or they could be added to the volume dumper's gate hc_backup_. Instead of giving *.SysDaemon access to all the branches in the storage system, the volume dumper switches (or new switches) could be used to control access via these entries. The volume dumper already uses a restricted gate, and is not given access to the hierarchy in any extensive fashion. However, both the volume dumper and the hierarchy dumper with the added restrictions discussed above would be processes with unusual abilities under the complete control of operations. All other such processes run in restricted environments to add assurance that the operators cannot exploit these abilities. Running the dumper processes in a restricted command environment would prevent the operators from exploiting the existing abilities of the hierarchy dumper except via a flaw in the dumper software. This MTB proposes restricted environments for the dumpers. Future work should examine restricting the hierarchy dumper process' access to the file system. 3_ R_E_L_O_A_D_E_R_S_ A_N_D_ R_E_T_R_I_E_V_E_R_S_ This MTB does not discuss reloaders and retrievers. It is the author's belief that these are inescapably privileged operations. Even the retrieval of a previous version of a segment or directory can be a serious security breach if it is done without proper authorization, since it can modify or destroy protected information. At a secure site, reloads and retrievals would only be run by trusted people. 4_ T_H_E_ R_E_S_T_R_I_C_T_E_D_ E_N_V_I_R_O_N_M_E_N_T_S_ For an initial implementation, the obvious approach is to construct a process overseer that calls an ssu_ subsystem that contains the dumper commands as "multics_requests," in the ssu_ Multics Technical Bulletin MTB-657 Backup Dumper Subsystems sense. This also offers the opportunity to improve the ease of use of these commands by assigning them more obvious (and in some cases, shorter) names. There are two possible approaches to the construction of the subsystem. The first is to construct a single subsystem with requests for both the hierarchy and volume backup dumpers. Such a subsystem would look like: Subsystem_name: backup_dumper Subsystem_ec_suffix: ec Subsystem_prompt: "Enter command (backup dumper)^/" Subsystem_requests: SUBSYSTEM REQUEST -> MULTICS COMMAND ----------------------------------------------- begin_hierarchy_incremental -> start_dump begin_hinc start_hierarchy_incremental start_hinc wakeup_hierarchy_incremental -> wakeup_dump wakeup_hierarchy wakeup_hinc end_hierarchy_incremental -> end_dump stop_hierarchy_incremental end_hinc stop_hinc hierarchy_catchup -> catchup_dump hcatchup hcat hierarchy_complete -> complete_dump hcomplete hcomp begin_volume_incremental -> incremental_volume_dump begin_vinc start_volume_incremental start_vinc wakeup_volume_incremental -> wakeup_volume_dump wakeup_volume wakeup_vinc MTB-657 Multics Technical Bulletin Backup Dumper Subsystems end_volume_incremental -> end_volume_dump stop_volume_incremental end_vinc stop_vinc volume_catchup -> volume_catchup_dump vcatchup vcat volume_complete -> volume_complete_dump vcomplete vcomp The second alternative is to create two subsystems, one for each dumper. Inside each subsystem, the markings "volume" and "hierarchy" would be omitted from the request names. The subsystem names would be "volume_backup_dumper" and "hierarchy_backup_dumper", and the prompts "Enter command (volume backup)" and "Enter command (hierarchy backup)". In all cases, the exec_com search list would be "backup_dumper". Since any given process should only be running one dumper at a time, the two subsystem approach seems easiest on the users. 5_ I_M_P_L_E_M_E_N_T_A_T_I_O_N_ C_O_N_S_I_D_E_R_A_T_I_O_N_S_ An initial implementation of both of the subsystem alternatives has been made. This implementation makes no changes to the code of the dumpers. They are called "as is." This, or course, means that any error messages that they produce continue to carry their old names. In addition, no provision is made for changing the default or permissible control arguments for any of the commands. A site might well want to insure that a particular set of control arguments were always used. This might be accomplished by providing a "one-way" abbrev request; the start_up exec_com could lock the process in to an abbrev profile with suitable command lines. This would require abbrev to have an option that would expand abbreviations while forbidding some or all of the abbrev control requests, such as ".u". All of this can be addressed in a future version. 6_ A_ M_I_N_O_R_ E_X_T_E_N_S_I_O_N_ T_O_ S_S_U__ The ssu_ implementation of "standard requests" in inappropriate for securely restricted subsystems. While a subsystem can use the "unknown_request" macro to disable a standard request, the implementor has no guarantee that a future version of Multics Technical Bulletin MTB-657 Backup Dumper Subsystems ssu_request_tables_$standard_requests will not add a request that allows the user unwanted privilege. Therefore, a new request table, ssu_request_tables_$restricted_requests, needs to be added. It contains all the the existing standard_requests except for the "execute" request. 7_ D_E_B_U_G_G_I_N_G_ A_N_D_ A_D_M_I_N_I_S_T_R_A_T_I_O_N_ Like the Initializer process, the dumper processes need some escape mechanism by which maintainers can reach ordinary command level. This will be implemented via an "admin" request, which will demand a assword. This password will be stored in the PNT. A future MTB on PNT management will discuss storing "admin" passwords.