MULTICS ADMINISTRATIVE BULLETIN MAB-057-03 To: MAB Distribution From: F. W. Martinson G. E. Johnson Date: March 26, 1986 Subject: Multics Configuration Management: Installing Emergency Changes in System Libraries Abstract: | This bulletin defines procedures for submitting software for | emergency installation into the Multics System Libraries. This | bulletin derives its authority from, and is published under, | Multics Configuration Management: Policy Statement, MAB-070. | Revisions: | Rev2) 08/85, GJohnson Revises the procedure for normal | installations to conform with requirements of | Configuration Management. | Rev3) 02/86, GJohnson Revised to require relative pathname | for developer's software directory and auditor's audit | directory on the MSCR Detail Sheet. | _________________________________________________________________ Multics Project internal working documentation. Not to be reproduced or distributed outside the Multics Project. - i - MAB-057-03 Installing Emergency Changes CONTENTS Page Introduction . . . . . . . . . . . . . . . . . . . 1 Data Security Critical Installations . . . . . . . 2 Preparation for Installing Emergency Changes . . . 2 Approval of Emergency Installations . . . . . . . . 3 Auditor Approval . . . . . . . . . . . . . . . . 3 Security Coordinator Approval . . . . . . . . . 4 Unit Manager Approval . . . . . . . . . . . . . 4 Processing the Emergency Installation . . . . . . . 5 Tracking Emergency Installations . . . . . . . . . 5 Resolution of Emergency Installations . . . . . . . 5 - ii - Installing Emergency Changes MAB-057-03 INTRODUCTION This is one of a series of MABs on Multics Configuration Management. MAB-070 gives an overview of the entire configuration management process. In particular, MAB-070 outlines policies for three types of software changes which are controlled by configuration management: o Planned changes to pre-release software and documentation, described in MAB-056. o Emergency changes to pre-release software and documentation, described in MAB-057. o Critical fix changes to released software and documentation, described in MAB-063. This MAB describes policies and procedures for the second of these three software change types. Emergency software modifications must be in conformance with Software Development Procedures as described in MAB-066. Definitions and descriptions may refer the reader to additional documentation for greater levels of detail on specific topics. For management authority describing enforcement and exceptions see MAB-070. A Multics System Change Request (MSCR) is required to install a fix for a critical problem as defined in MAB-044. A critical problem would be one which: 1) causes a system to crash, 2) irreparably compromises data security or integrity, 3) prevents important subsystems from operating, inconveniencing many users. If an emergency installation corrects a critical problem that exists in a distributed Multics Release a critical fix will be transmitted, as appropriate, to affected customer sites. Refer to MAB-063 for a discussion of critical fixes. Critical errors have traditionally been identified by customer Trouble Reports, developer testing, or diagnosis of crashes at a Multics Development Center (e.g., Phoenix, ACTC, or CISL). Problems encountered within two (2) weeks of a planned installation must be corrected by a Post-Submission Bug Fix (PBF) as described in MAB-056, under the Post-Submission Bug Fixes section. - 1 - MAB-057-03 Installing Emergency Changes Installations suitable for emergency submission may be installed: - without an approved MCR - without documentation unit approval Once the emergency installation has been made, the submitter must resubmit the fix through the process for planned installations as defined in MAB-056. This process must be initiated within five (5) working days of the emergency installation and completed before the next Multics Release is shipped to Customer Service Division for distribution to customer sites. DATA SECURITY CRITICAL INSTALLATIONS Data security critical fixes shall be submitted for installation on System M as an emergency change. An emergency change for a data security fix must follow the procedure described in MAB-063. The online information segments will provide a brief description of the fix without specific reference to any data security significance. All other procedures, as identified below, will be followed. PREPARATION FOR INSTALLING EMERGENCY CHANGES Code modified for planned changes must have been developed in conformance with Software Development Procedures, MAB-066. Coding and auditing must conform to published Multics standards in effect at the time modified code is submitted for installation. 1. PREPARE INSTALLATION: Modified segments should be placed in one directory. Access to the modules being submitted should be set as follows: Change Directories Change Segments -------------------------- -------------------------- sma DEVELOPER.PROJECT.* re DEVELOPER.PROJECT.* s AUDITOR.PROJECT.* re AUDITOR.PROJECT.* sma *.SysDaemon.* re *.SysDaemon.* null *.*.* null *.*.* - 2 - Installing Emergency Changes MAB-057-03 New and modified source modules must contain appropriate history comments. The developer must add the history comments by using the history_comment (hcom) command described in Multics Configuration Management: Tracking Software Changes for MR12.0, MTB-716. A history comment may be added by typing: hcom add path {-control_args} The developer is responsible for adding software protection notices. Refer to Standards for Software Protection, MAB-052 for information on pnotices. Online, type " help add_pnotice". 2. PREPARE MSCR: Prepare a Multics System Change Request (MSCR) as described in MAB-056. Indicate EMERGENCY Change by checking the third line from the top left corner. Line B of the detail sheets, described in MAB-056, should be filled | in with the developer's software directory. The pathname of | the auditor's installation directory should be filled in by | the auditor. | 3. SUBMITTOR'S APPROVAL: The submitter's signature verifies that the code completely implements changes described by the MCR(s) and that all coding and testing has been in compliance with project plans and published standards. Reference Multics Programming Standards, MAB-068. 4. SUBMIT FOR AUDIT: The developer provides the pathname of the installation directory to the auditor for auditing, as defined in MAB-069. After the audit, the developer and auditor decide if the software is ready to install or if it must be changed to correct audit failures. When the software is ready to install, the developer's responsibility in the emergency installation procedure ends. APPROVAL OF EMERGENCY INSTALLATIONS Auditor Approval When auditing begins the auditor has control over the code being installed. Access to the modules being submitted should be set as follows: - 3 - MAB-057-03 Installing Emergency Changes Change Directories Change Segments ----------------------------- ----------------------------- s DEVELOPER.PROJECT.* re DEVELOPER.PROJECT.* sma AUDITOR.PROJECT.* re AUDITOR.PROJECT.* s SEC_COORD.PROJECT.* re SEC_COORD.PROJECT.* s MANAGER.PROJECT.* re MANAGER.PROJECT.* s *.SysMaint.* re *.SysMaint.* sma *.SysDaemon.* re *.SysDaemon.* null *.*.* null *.*.* | The pathname of the developer's software directory and the | auditor's installation directory must be identified in Section B | of the MSCR Detail Sheet. The Auditor's signature implies auditing procedures have been in compliance with Guidelines for Auditing Software, MAB-069. Auditor's signature verifies that the MSCR form is complete and * accurate. The completed MSCR, Detail Sheets, and Audit Checklist forms should be given to the appropriate Unit Manager. When the proposed submission involves modules identified as part of the Trusted Computing Base (TCB) the installation package should be given to the Security Coordinator instead of the Unit Manager. Security Coordinator Approval Installation policy and procedure specifically charters the Security Coordinator to audit the security aspects of modified modules and include files which are a part of, or used by, the TCB. The signature of the Security Coordinator provides reasonable assurance that the modifications to be installed have no negative impact on the TCB or the security of the Operating System. When the Security Coordinator approves an emergency installation the MSCR form, Detail Sheet, and Audit Checklist must be given to the appropriate Unit Manager. Unit Manager Approval The Manager's signature provides final authorization that the emergency change is ready and appropriate for installation. The Manager forwards the MSCR package to the Project Leader, Software Integration Project, Phoenix, Arizona. All source segments must be available on system M and must not contain any functional improvements. - 4 - Installing Emergency Changes MAB-057-03 PROCESSING THE EMERGENCY INSTALLATION The Project Leader, Phoenix System Integration Project, or designate, prepares the emergency installation based on the MSCR package. A unique number is assigned to the MSCR form to identify the emergency fix and provide for efficient tracking. A unique Installation_id number is also assigned. The Phoenix System Integration Project staff will install the emergency change. TRACKING EMERGENCY INSTALLATIONS Successful installation of the modules associated with the emergency change will cause details of the installation to be placed in the emergency installation tracking database referencing the unique Emergency ID number and the installation database referencing the Installation_id number. The Emergency ID number will be sent, via Multics mail, to the submitter and the responsible unit manager. Refer to MTB-716 for details. RESOLUTION OF EMERGENCY INSTALLATIONS The Unit Manager of the developer is responsible for the timely resolution of outstanding emergency changes. Closing an outstanding emergency installation requires a planned change which is in compliance with MAB-056. These steps must be initiated within five (5) working days of the emergency installation and satisfied before the next scheduled Multics Release. - 5 -