MULTICS ADMINISTRATIVE BULLETIN MAB-063-01 To: MAB Distribution From: Gary C. Dixon Date: August 13, 1985 Subject: Multics Configuration Management: Critical Fixes for Released Software ABSTRACT This MAB describes policies and procedures for preparing and distributing critical fixes to sites. Critical fixes are grouped into two categories, based upon their impact on system security. The categories are nonsecurity problems and data security problems. Separate procedures are used for announcing each kind of fix. Revision 01 of this MAB introduces auditing of critical fixes, | use of the history_comment command into the critical fix | configuration management process, and updates Appendix A to | reflect several new tools developed since revision 00 was | published. | _________________________________________________________________ Multics Project internal working documentation. Not to be reproduced or distributed outside the Multics Project. - i - MAB-063-01 Critical Fixes CONTENTS Page 1: Policies for Critical Fixes . . . . . . . . . . 1 1.1: Objectives . . . . . . . . . . . . . . . . . 1 1.2: Definition of Terms . . . . . . . . . . . . . 1 1.2.1: Security Impact of Critical Fixes . . . . . 2 1.2.2: People Involved . . . . . . . . . . . . . . 4 1.2.3: Steps Involved . . . . . . . . . . . . . . 5 1.3: Restatement of Objectives as Policies . . . . 6 POLICY 1: Deciding to Have a Fix . . . . . . 6 POLICY 2: Selecting Multics Releases to Fix 6 POLICY 3: Categorizing as a Data Security Fix . . . . . . . . . . . . . . . . . . . . 6 POLICY 4: Creating and Testing the Fix . . . 6 | POLICY 5: Auditing the Fix . . . . . . . . . 6 POLICY 6: Notifying that the Fix can be Distributed . . . . . . . . . . . . . . . . 7 POLICY 7: Installing a Critical Fix in Pre-Release Software . . . . . . . . . . . . 7 POLICY 8: Installing the Fix in the Critical Fix Library . . . . . . . . . . . . . . . . 7 POLICY 9: Approving Announcement of a Fix . 8 POLICY 10: Announcing a Nonsecurity Fix . . 8 POLICY 11: Installing a Nonsecurity Fix at a Site . . . . . . . . . . . . . . . . . . . . 8 POLICY 12: Updating Trouble Reports for a Nonsecurity Fix . . . . . . . . . . . . . . 8 POLICY 13: Announcing a Data Security Fix . 9 POLICY 14: Requesting Access to a Data Security Fix . . . . . . . . . . . . . . . . 9 POLICY 15: Installing a Data Security Fix at a Site . . . . . . . . . . . . . . . . . . . 9 2: Procedures for Critical Fixes . . . . . . . . . 11 2.1: Fix Creation . . . . . . . . . . . . . . . . 11 2.1.1: Decision to Create . . . . . . . . . . . . 11 2.1.1.1: Criteria for Deciding . . . . . . . . . . 11 2.1.1.2: Severity of the Problem . . . . . . . . . 11 2.1.1.3: Releases Which Should Be Fixed . . . . . 12 2.1.2: Categorization as Data Security Fix . . . . 12 2.1.3: Creating the Fix . . . . . . . . . . . . . 13 2.1.3.1: Protecting Data Security Fixes during Creation . . . . . . . . . . . . . . . . . . . . . 14 ii Critical Fixes MAB-063-01 CONTENTS (cont) Page 2.1.4: Testing the Fix . . . . . . . . . . . . . . 15 2.1.5: Auditing the Fix . . . . . . . . . . . . . 16 | 2.1.5.1: Auditing Materials . . . . . . . . . . . 16 | 2.1.5.2: Copy Auditing Materials and Restricting | Access . . . . . . . . . . . . . . . . . . . . . . 16 | 2.1.5.3: Auditor's Review, Auditing Results . . . 17 | 2.1.6: Notifying the Critical Fix Coordinator . . 18 | 2.1.7: Installing Critical Fixes in Pre-Release | Software . . . . . . . . . . . . . . . . . . . . . 19 | 2.1.7.1: Installing Nonsecurity Fixes . . . . . . 19 | 2.1.7.2: Installing Data Security Fixes . . . . . 19 | 2.2: Fix Distribution . . . . . . . . . . . . . . 21 2.2.1: Installing the Fix . . . . . . . . . . . . 21 2.2.1.1: Critical Fix Library . . . . . . . . . . 21 2.2.1.2: Critical Fix Directory . . . . . . . . . 21 2.2.1.3: Protecting Data Security Fixes during Installation . . . . . . . . . . . . . . . . . . . 23 2.2.2: Announcing the Fix . . . . . . . . . . . . 26 2.2.2.1: Announcing a Nonsecurity Fix . . . . . . 26 2.2.2.2: Announcing a Data Security Fix . . . . . 26 2.2.2.2.1: Contents of Mailed Announcements . . . 27 2.2.2.2.2: Site Security Fix Distributor . . . . . 27 2.2.2.2.3: Foreign Affiliate Security Fix Distributor . . . . . . . . . . . . . . . . . . . 28 2.2.3: Transmitting Critical Fixes to the Site . . 30 2.2.3.1: Methods of Transmission . . . . . . . . . 30 2.2.3.2: Protecting Data Security Fixes at the Site . . . . . . . . . . . . . . . . . . . . . . . 30 2.2.4: Installing Critical Fixes at the Site . . . 32 2.2.5: Updating TRs Associated with a Fix . . . . 33 Appendix A: Tools for Critical Fixes . . . . . . . 34 cpaf.ec . . . . . . . . . . . . . . . . . . . . 35 create_fix_dir.ec (cfd.ec) . . . . . . . . . . . 36 create_fix_link.ec (cfl.ec) . . . . . . . . . . 38 create_release_dir.ec (crd.ec) . . . . . . . . . 40 cv_cpa_to_ec.ec (ccte.ec) . . . . . . . . . . . 41 cwd_fix.ec (cwdf.ec) . . . . . . . . . . . . . . 44 give_access_to_all_fixes.ec . . . . . . . . . . 47 give_access_to_fix.ec (gatf.ec) . . . . . . . . 48 lib.ec . . . . . . . . . . . . . . . . . . . . . 50 ^lib.ec . . . . . . . . . . . . . . . . . . . . 52 next_fix_number.ec (nfn.ec) . . . . . . . . . . 53 protect_fix.ec (pf.ec) . . . . . . . . . . . . . 54 secfix.ec . . . . . . . . . . . . . . . . . . . 55 | Appendix B: Guidelines for Security Fix Distributors . . . . . . . . . . . . . . . . . . . 63 - iii - Critical Fixes MAB-063-01 1: POLICIES FOR CRITICAL FIXES 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 last of these | three software change types. Section 1 of the MAB describes | policies which govern the development and distribution of | critical fixes. Section 2 describes the detailed procedures | which are used to implement these policies. | 1.1: Objectives The main objective of installing critical fixes is to provide a | method for resolving problems in supported Multics software | releases when the problems are severe, and customers cannot afford to wait for a fix provided in the next software release. Secondary objectives are to protect the security of data stored on Multics systems when data security problems are found; and minimize the Multics Development Center (MDC) resources needed to distribute critical fixes. These objectives are described imprecisely, but they convey the nature of what is to be achieved. In order to define the objectives more precisely, several terms must be defined. 1.2: Definition of Terms The phrase "released Multics software" refers to all releases of | Multics software which have been transmitted to the CSD Software | Library for distribution to customer sites. | The phrase "supported Multics software releases" refers to the Multics Release most recently transmitted by MDC to the CSD Software Library for distribution to customer sites (eg, MR10) and the immediately prior release (eg, MR9). MDC is committed to providing fixes for critical problems found in these supported - 1 - MAB-063-01 Critical Fixes | releases on a timely basis. Subreleases (eg, MR10.0, MR10.1 and | MR10.2) are counted as parts of a single major release (eg, MR10) | for purposes of determining which releases to fix problems in. | The phrase "pre-release Multics software" refers to the Multics Release which is currently being prepared for distribution to | customer sites. This pre-release software has not been shipped | to customers. The term "critical fix" is a shorthand way of saying "a fix for a critical problem". A "critical problem" is a software problem that severely impacts system reliability or availability, or which compromises data integrity or data security. 1.2.1: SECURITY IMPACT OF CRITICAL FIXES Most critical fixes deal with system reliability problems (system crashes), malfunctions of important subsystems (preventing acceptable system operation), or data integrity failures (loss of data). While these problems interfere with proper operation of the system, they do not jeopardize the data security capabilities of the system. However, some problems can enable data security errors (unauthorized disclosure of data, unauthorized destruction or modification of data, or denial of authorized data access). Because such data security problems could have a severe impact on the safety of customer data files, special precautions are taken when developing and distributing fixes for data security errors. These precautions are intended: to restrict knowledge of the problem only to those who have a need to know; and to maintain an accurate record of individuals to whom the information was released. To implement this special handling of security problems, critical fixes are grouped into two categories: Data Security Fixes: critical fixes for problems which: allow unauthorized users to access the system; or allow users unauthorized access to data; or allow nonprivileged users to crash the system in a reliable or near-reliable fashion (one form of denial of access to data). Nonsecurity Fixes: critical fixes for problems which are not data security problems, as defined above. - 2 - Critical Fixes MAB-063-01 It is known that data security problems can arise: only in | modules of the Trusted Computing Base (TCB), which consists of | modules in ring 0, ring 1 and in privileged applications; or in | any improperly coded program used in a trusted process. | Privileged applications are subsystems such as I/O Daemon and | Volume Backup software which run in a Trusted Process, which use | special access or resources (eg, printer devices) not normally | available to users, which access data on behalf of another user, | and which validate that user's access to the data. Not all problems occurring in TCB modules affect data security. Therefore, this definition states only that any fix to a module in the Trusted Computing Base (TCB), or module used by a trusted | process, is a candidate for being a Data Security Critical Fix. | Each such fix must be evaluated to determine its real impact on data security. - 3 - MAB-063-01 Critical Fixes 1.2.2: PEOPLE INVOLVED The following people are involved in preparing a critical fix: Developer the person responsible for the software module which has the | problem, and who provides the critical fix for the problem. | Auditor | the person who audits the critical fix. Multics Security Coordinator the person within MDC responsible for evaluating the security impact of changes to the Multics system. Manager the unit manager within the Multics Development Center (MDC) having overall responsibility for the area of the system which has the problem. This person may or may not be the developer's immediate manager. Critical Fix Coordinator the person within the Multics Software Support (MSS) unit of * MDC responsible for distributing critical fixes to sites. Site Systems Analyst (Site SA) the person who provides technical support to a customer site, and who interfaces with MDC to resolve problems at the site. Site Security Fix Distributor the single Site SA for each U.S. site designated as the primary interface with MDC for distribution of data security critical fixes to the site. Foreign Affiliate Security Fix Distributor the single Technical Assistance Center (TAC) staff member for each foreign affiliate company (eg, HIS Canada, HIS United Kingdom, CII-Bull) designated as the primary interface with MDC for distribution of data security critical fixes to his company's customers via Site SAs at each customer site. - 4 - Critical Fixes MAB-063-01 1.2.3: STEPS INVOLVED The critical fix mechanism is composed of two major operations: o development of a critical fix; and o distribution of a critical fix to customer sites. Critical fix development consists of seven steps: | o deciding that a critical fix should be created; o categorizing the fix as a data security critical fix or nonsecurity critical fix; o creating the fixed modules; o testing the fixed modules o auditing the fixed modules; | o making the fix available to the Critical Fix Coordinator; and | o installing the fix into pre-release software libraries. | Critical fix distribution consists of five steps: o installing the critical fix into a Critical Fix Library; o announcing the availability of the critical fix for use by sites; o transmitting the critical fix to each site; o installing the critical fix at the site; and o annotating TRs associated with the problem to indicate that the critical fix is a bypass or correction for the problem. - 5 - MAB-063-01 Critical Fixes 1.3: Restatement of Objectives as Policies Using the definitions above, the objectives in section 1.1 can now be restated more precisely as a series of policies for managing critical fixes. POLICY 1: Deciding to Have a Fix Whenever a critical problem is discovered in supported Multics software which has been released to customers, the developer and unit manager responsible for the software shall jointly decide whether a critical fix should be created. POLICY 2: Selecting Multics Releases to Fix If a critical fix is created, versions of the fix should be provided for all supported Multics Releases which have the problem. POLICY 3: Categorizing as a Data Security Fix The Multics Security Coordinator shall evaluate each fix to a module in the Trusted Computing Base to categorize the fix either as as a data security critical fix or a nonsecurity critical fix according to the definition above. Fixes to modules outside the TCB will automatically be categorized as nonsecurity fixes. POLICY 4: Creating and Testing the Fix The developer responsible for the software creates and tests the | critical fix modules for the appropriate software releases. All | fixed modules must have an appropriate history comment. During creation and testing (and subsequent distribution) of a data security critical fix, the developer shall limit knowledge of the problem and its fix to people who have a need to know this information. | | | POLICY 5: Auditing the Fix | | All critical fixes must be audited, according to standard | guidelines for software auditing described in MAB-069. The | auditor will have control over the software during the audit and | subsequent submission to the Critical Fix Coordinator. The | auditor must update the history comments to indicate that fixes | have been audited. - 6 - Critical Fixes MAB-063-01 POLICY 6: Notifying that the Fix can be Distributed When the critical fix has been created and tested, and is ready for distribution, the auditor notifies the Critical Fix | Coordinator that the fix is ready to install. The notification includes full information describing the problem and the fix, plus an auditing checklist showing the results of the audit. For | data security fixes, the Multics Security Coordinator shall be sent a copy of this notification. POLICY 7: Installing a Critical Fix in Pre-Release Software If the problem also affects pre-release software, then the | developer and auditor must submit an MSCR for an emergency | change, following the procedures described in MAB-057. | | For a data security problem in pre-release software, a slightly | modified procedure must be followed. The Multics Security | Coordinator must delay submission of the MCR to the MCR Board | until two (2) months after announcement of the data security fix | to Site and Foreign Affiliate Security Fix Distributors. This is | to prevent knowledge of the problem from reaching the field | before sites have had time to apply the data security fix. The | exact details of the procedure are given below. | POLICY 8: Installing the Fix in the Critical Fix Library When notified that a critical fix is ready for installation, the Critical Fix Coordinator shall update history comments in the | fixed modules, and install the fix into the Critical Fix Library | on System M. The coordinator prepares an announcement message | which describes the symptoms of the problem being fixed, plus additional information needed by Site SAs to determine if the fix should be installed at their site. When installing a data security critical fix, the Critical Fix Coordinator shall limit access to the installed copy of the fix to those people with a need to know this information. Information in the fix description shall include only a brief description of symptoms; it shall not include a description of the problem itself, or of methods for exploiting the problem to bypass security or cause system crashes. The Critical Fix Coordinator shall place overview information about the problem and methods of exploiting security in a segment in a separate part of the Critical Fix hierarchy. This information must not include a detailed analysis telling how to exploit the security problem. It should only provide enough | detail to act as a historical record of the data security error | for use within MDC. Access to this information shall be limited | - 7 - MAB-063-01 Critical Fixes to the Critical Fix Coordinator, who uses the information only to determine if the problem may be occurring at their customer | sites, and to other individuals within MDC who have a need to | know. The information shall not be released to customers, to | other Site SAs, or to Foreign Affiliate Security Fix | Distributors. POLICY 9: Approving Announcement of a Fix Prior to announcement of a nonsecurity critical fix, the installed fix and its description must be approved by the developer and unit manager responsible for the area of the system being fixed. For a data security critical fix, approval of the Multics Security Coordinator is required, in addition to approval by the developer and manager. Also, if the critical fix is being tested on System M, a successful evaluation of its exposure on System M must be provided by the System Integration Project Leader prior to announcing the fix. POLICY 10: Announcing a Nonsecurity Fix After announcement of a nonsecurity critical fix has been approved, the Critical Fix Coordinator announces the fix by placing the prepared fix description into the Critical_Fixes forum meeting. Site SAs have access to attend this meeting, and are encouraged to attend the meeting on a regular basis. POLICY 11: Installing a Nonsecurity Fix at a Site The Site SA for each site has the responsibility for deciding what critical fixes to install at his site, for transmitting the chosen fixes to the site, and for installing the fixes at the site. Foreign affiliate TAC personnel may assist SAs at their company's sites in installing such fixes. POLICY 12: Updating Trouble Reports for a Nonsecurity Fix After announcement of a nonsecurity critical fix, the Critical Fix Coordinator enters a transaction for each Trouble Report (TR) associated with the critical fix to indicate that the critical fix exists and applies to the given TR. For normal priority TRs, an added_info transaction is sufficient. For high and critical priority TRs, the critical fix can be used as a bypass for the - 8 - Critical Fixes MAB-063-01 problem; having a bypass justifies reducing the problem to normal priority. POLICY 13: Announcing a Data Security Fix After the announcement of a Data Security Critical Fix has been approved, the Critical Fix Coordinator shall announce the fix by sending mail requesting acknowledgment to each Site Security Fix Distributor and Foreign Affiliate Security Fix Distributor. This mail includes the fix number and the releases that are fixed, and gives a reply address for the Critical Fix Coordinator. The Critical Fix Coordinator has the responsibility for selecting each Site Security Fix Distributor, with the advice of the primary Site SA for each site. The Critical Fix Coordinator has the responsibility for selecting each Foreign Affiliate Critical Fix Coordinator, with the advice of the Technical Assistance Center (TAC) manager for each affiliated company. And the Critical Fix Coordinator is responsible for informing all Site and Foreign Affiliate Security Fix Distributors of their responsibility to limit information about data security fixes only to those site personnel having a need to know this information. POLICY 14: Requesting Access to a Data Security Fix Site or Foreign Affiliate Security Fix Distributors desiring access to the fix shall reply to the announcement mail, asking for access to specific release versions of the fix. The Critical Fix Coordinator shall acknowledge the reply by granting access to the fix directory, and by sending mail which gives the pathname of the critical fix and which states the responsibilities of the Site/Foreign Affiliate Fix Distributor to prevent improper disclosure of the fix. POLICY 15: Installing a Data Security Fix at a Site The Site Security Fix Distributor has the responsibility for transmitting each data security fix to his site, for protecting the fix information at his site, and for installing the fix without announcement at his site. The Foreign Affiliate Security Fix Distributor may either transmit and install each data security fix at his company's sites; or he may designate a Site Security Fix Distributor for some or all of his company's sites, and have the site distributor transmit and install each data security fix at that site. In either case, the designated security fix distributor has - 9 - MAB-063-01 Critical Fixes responsibility for preventing unauthorized disclosure of the fix or its descriptive information. - 10 - Critical Fixes MAB-063-01 2: PROCEDURES FOR CRITICAL FIXES This section of the MAB describes the procedures to be used to implement the policies in section 1. 2.1: Fix Creation The process of creating a critical fix involves seven steps: deciding that a particular problem is serious enough to justify having a critical fix; deciding whether the fix is a data security fix; creating versions of the fix for appropriate releases; testing the fix; and notifying the Critical Fix Coordinator when the fix is ready. 2.1.1: DECISION TO CREATE When the developer responsible for a software module identifies a problem in software which has been distributed to customers, he must decide if the problem is serious enough to warrant creation of a critical fix. Usually, this decision is made after consulting with the Critical Fix Coordinator and with the unit manager responsible for the area of the system containing the software module. The System Integration Project Leader may be consulted as well. 2.1.1.1: Criteria for Deciding The following factors should be weighed when deciding whether a given problem is serious enough to warrant creation of a critical fix: severity of the problem; and, releases which should be fixed. 2.1.1.2: Severity of the Problem As a general rule, problems warranting a critical fix should meet the TR system's guidelines for critical priority. These guidelines are: A) the problem interferes with system operation to an extent that the usefulness of the system is significantly limited for most users of the system; or B) the problem irreparably compromises the security or integrity of data stored in the system. Critical data storage problems must affect many files on the system, or must affect files which are difficult to retrieve or recreate (eg, a MRDS database, or files on backup tapes). - 11 - MAB-063-01 Critical Fixes 2.1.1.3: Releases Which Should Be Fixed The Multics Development Center is committed to supporting the currently shipped release (eg, MR10) and the immediately prior release (eg, MR9). A reasonable guideline is to provide a critical fix only for those supported releases in which the problem exists. If a problem occurs only in unsupported releases, then a critical fix usually isn't worthwhile. Contact the Critical Fix Coordinator for information on releases which are currently supported or are in use at sites. 2.1.2: CATEGORIZATION AS DATA SECURITY FIX If the problem addressed by a critical fix exists in a module of the Trusted Computing Base (TCB, which consists of ring zero, | ring one and privileged applications), or is a problem which can | occur in a Trusted Process, then the developer should discuss this problem with the Multics Security Coordinator to determine if the critical fix should be classified as Data Security Fix. The Security Coordinator will make this determination based upon the description of the problem provided by the developer and | knowledge of the TCB and trusted processes. - 12 - Critical Fixes MAB-063-01 2.1.3: CREATING THE FIX The developer responsible for the software module exhibiting the problem also has responsibility for developing critical fixes for appropriate releases of the module. For each Multics release to be fixed, the fix should be applied to the base software module shipped with that release. This allows the Critical Fix Coordinator to create a compare_ascii output file showing only what has been changed as part of this fix. Site SAs use such information to determine what is changing as a result of the fix when deciding whether to install the fix at their site. If earlier critical fixes have been applied to the module being fixed, merge_ascii can be used to merge the current fix with previous fixes. When earlier critical fixes apply, the developer should give the Critical Fix Coordinator two source modules: one containing just the current fix; and one containing the merged version. The developer should test the merged version, as described in section 2.1.4. Source for prior releases is available on the Release Logical Volume on System M. The best way to access such source is to use lib.ec (>udd>sm>fixes>lib.ec) to attach the logical volume and select an appropriate library descriptor, and the library_fetch command to extract source from the release libraries using the selected descriptor. For example, to extract the MR10.1 source for verify_lock.pl1, you could do the following: ec >udd>sm>fixes>lib 10.1 lf -lb h.s verify_lock.* -lg -into ===.10.1 Use the ^lib exec_com to restore the normal library descriptor and to detach the Release logical volume: ec >udd>sm>fixes>^lib Make as few changes as possible to the original source. Don't add or remove blank lines unnecessarily, or change indentation, or make other changes that would add clutter to the compare_ascii output. This will make it easier for Site SAs to understand and apply the fix. Be sure to add a history line comment indicating your change | using the history_comment tool described in MTB-716. A sample | command line is: | | hcom add prog.pl1 -napv | | You will be prompted for required information. | - 13 - MAB-063-01 Critical Fixes 2.1.3.1: Protecting Data Security Fixes during Creation During creation of data security fixes, the developer is responsible for preventing information about the problem from being disclosed to anyone other than people having a need to know of the problem and its fix. In general, knowledge of the problem should be limited to: o the responsible developer; o the responsible unit manager; o coworker(s) whose advice is needed in preparing the fix; | o the auditor; o the Multics Security Coordinator; o the Critical Fix Coordinator; and o the System Integration Project Leader, who will install a | version of the fix on System M as an emergency change. Access to the fix itself should be limited as follows: | Fix Directory Fix Segments | ----------------------------- ----------------------------- | sma DEVELOPER.PROJECT.* re DEVELOPER.PROJECT.* | s AUDITOR.PROJECT.* re AUDITOR.PROJECT.* | s SEC_COORD.PROJECT.* re SEC_COORD.PROJECT.* | s MANAGER.PROJECT.* re MANAGER.PROJECT.* | s CRIT_FIX_COORD.PROJECT.* re CRIT_FIX_COORD.PROJECT.* | sma *.SysDaemon.* re *.SysDaemon.* | null *.*.* null *.*.* - 14 - Critical Fixes MAB-063-01 2.1.4: TESTING THE FIX The developer is responsible for testing all versions of the critical fix. At a minimum, the following levels of testing should be performed: A) Make sure that the fixed modules can be recompiled with the compiler and include files distributed with the release to which the fix applies. B) Test an equivalent fix against the current software running on the CISL Development System or on System M. For online software, this may involve testing with a special version of the software module used in your process. For hardcore changes, this may involve testing with a special hardcore tape using block time on a test system. For changes to the TCB, the testing | must involve running the appropriate functional test | cases, and verifying that their output is correct. | C) After gaining confidence in the version of the fix which applies to the software running on System M, submit an emergency change to get immediate | installation of this fix on System M. This will allow wider exposure of the algorithms used in the fix prior to its distribution to sites. Follow the procedures in MAB-057 for submitting emergency changes. D) When a hardcore fix applies to several releases, and a significant difference exists between fix versions for the releases, then each version should be checked out by booting a special Multics System Tape containing the fixed module for each release being fixed. This testing should be done during block time on a test system, using the appropriate released software as a base to which the fix is applied. Level A testing must be performed for every fix. Level B testing must be performed, except in cases where appropriate hardware is not available to test the effectiveness of the fix. In such cases, the developer much at least insure that the system runs with the fixed module installed, and must satisfy himself and the responsible unit manager that the fix is correct. Level C testing must be performed for all hardcore changes, and may be performed for other changes as well. Level D testing must be performed, as required by the nature of the fix. Exceptions to testing requirements can be granted by the Critical Fix Coordinator. - 15 - MAB-063-01 Critical Fixes | 2.1.5: AUDITING THE FIX | | The version of a critical fix for each software release must be | audited according to the Guidelines for Auditing Software in | MAB-069. MAB-069 describes specific procedures for auditing | critical fixes. In addition, MAB-069's guidelines for items to | check when auditing software apply to critical fixes. | | | 2.1.5.1: Auditing Materials | | The developer should supply the auditor with the following | information. | | o The pathname of, and access to, the actual modules to be | audited. | | o The pathname of, and access to, a Critical Fix Announcement | segment, containing the following items: | | o symptoms of the problem, | o description of the problem, | o numbers of TRs and error list entries associated with | the problem, | o releases in which the problem exists, | o releases to which the fix applies, | o names of modules being fixed, and names of their | containing bound segments, | o review procedures to be used (either TCB or nonTCB), | o fix type (either nonsecurity fix, or data security | fix), and | o level of testing of the fix, along with a brief | description of the types of tests which were run. | | For examples of the type and format of information needed, look | at some of the later transactions in the Critical_Fixes forum | (>udd>sm>fixes>Critical_Fixes or fixes, for short). | | | 2.1.5.2: Copy Auditing Materials and Restricting Access | | The auditor must copy the critical fix software and Critical Fix | Announcement segment into his own hierarchy, and set access to | prevent the developer from modifying these modules during | auditing and installation of the fix. Access to the fix itself | should be limited as follows, for both data security and | nonsecurity fixes: - 16 - Critical Fixes MAB-063-01 Fix Directory Fix 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 CRIT_FIX_COORD.PROJECT.* re CRIT_FIX_COORD.PROJECT.* | sma *.SysDaemon.* re *.SysDaemon.* | null *.*.* null *.*.* | | | 2.1.5.3: Auditor's Review, Auditing Results | | The auditor must review the changes using the auditing checklist | described in MAB-069. Then the auditor and developer discuss the | results of the audit. Only when developer and auditor agree that | the critical fixes are ready for installation does the | installation proceed. | - 17 - MAB-063-01 Critical Fixes | 2.1.6: NOTIFYING THE CRITICAL FIX COORDINATOR | | When the critical fix has been created, tested, and all audit | checklist items have been passed or waived,, the auditor approves | installation of the fix by updating the history comments in all | modules to include his personid as auditor. This should be done | using the history_comment tool described in MTB-716.(1) A sample | command line is: | | hcom add_field prog.pl1 -audit | | Then the auditor notifies the Critical Fix Coordinator by | electronic mail that the fix is ready to be installed and | announced. This mail consists of: | | o The pathname of the auditor's copy of the fixed modules. | | o The pathname of the Critical Fix Announcement segment, which | the auditor copied into his audit hierarchy. | | o A copy of the completed auditing checklist, showing the | results of the audit. | | If a hardcopy auditing checklist was used, then the hardcopy | checklist must be delivered to the Critical Fix Coordinator prior | to installation of the critical fix. If an online version of the | checklist was used, then send the pathname of the online | checklist to the Critical Fix Coordinator via electronic mail. | | For all TCB changes, the auditor must send a copy of the | notification mail to the Multics Security Coordinator, as well as | to the Critical Fix Coordinator. The Security Coordinator must | send mail to the Critical Fix Coordinator authorizing the changes | to the TCB, and indicating whether the fix is a data security | critical fix or nonsecurity fix. _________________________________________________________________ (1) After the auditor updates the history comments, the approve and install fields are still blank. They will be filled in by the Critical Fix Coordinator when the fixed modules are installed in the Critical Fix Library. - 18 - Critical Fixes MAB-063-01 2.1.7: INSTALLING CRITICAL FIXES IN PRE-RELEASE SOFTWARE | | Problems which affect Multics Releases which have already been | distributed to customers may also affect pre-release software | currently under development. Critical fixes for such problems | may be applied to pre-release software as an emergency change. | | | 2.1.7.1: Installing Nonsecurity Fixes | | The developer submits an MSCR for an emergency change to install | a nonsecurity fix into pre-release software libraries, exactly as | described in MAB-057. The same person who audited the critical | fix should also audit the emergency change to pre-release | software. | | | 2.1.7.2: Installing Data Security Fixes | | If a data security problem exists in pre-release software, then | its fix must be submitted for installation on System M as an | emergency change. This allows the fix to be exposed on System M, | and also protects System M from the effects of the security | problem. | | A special procedure should be used to submit a data security fix | as an emergency change. | | 1. PREPARE MCR: The developer writes an MCR describing the | nature of the problem and the impact of the problem on data | security. However, the MCR must not state the method for | exploiting the security problem. The developer DOES NOT | SUBMIT THIS MCR to the MCR Board. | | 2. PREPARE MSCR: The developer fills out an MSCR form for an | emergency change, as described in MAB-057. He attaches the | unapproved MCR to the MSCR package, and passes this package | to the auditor for review of the emergency change to the | System Libraries. The same person who audits the critical | fix to released software should also audit the emergency | change to pre-release software. | | 3. AUDIT: The auditor reviews the change, according to | auditing procedures described in MAB-069. When the steps in | MAB-069 are complete, the auditor signs approval on the MSCR | form, and forwards the MSCR package (which now consists of | the MSCR, unapproved MCR, auditing checklist, and modified | software) to the Multics Security Coordinator. | | 4. SECURITY AUDIT: The Security Coordinator reviews the | security aspects of the change and its impact on the TCB. | When he agrees that the change is correct, he signifies | - 19 - MAB-063-01 Critical Fixes | approval by signing the emergency change MSCR form. He | removes the unapproved MCR from the MSCR package, and passes | the remainder of the package along to the responsible | manager for approval of the emergency change. From this | point on, the data security fix is handled as a standard | emergency change, as described in MAB-057. | | 5. MCR SUBMISSION: The Security Coordinator is also | responsible for submitting the MCR to the MCR Board for | review and approval. MCR submission must be delayed until | at least two (2) months after formal announcement of the | data security fix (as described by Section 2.2.2) in order | to protect information about the problem. | | If less than two months remain between the announcement date | and shipment of pre-release software to the CSD Software | Library, then the fix can be shipped with the release based | upon the emergency change installed on System M. Then a | follow-up MCR can be submitted once the two months have | elapsed to resolve the emergency change. Refer to MAB-057 | for further details of the emergency change process. | | 6. PLANNED CHANGE: Once the MCR is approved, the Multics | Security Coordinator and the responsible Manager jointly | share the responsibility to coordinate permanent | installation of the data security fix into the pre-release | software libraries, according to the procedures for | installing planned changes in System Libraries described in | MAB-056. Installing a planned change is required by MAB-057 | to provide for MCRB and documentation unit review of the | change. - 20 - Critical Fixes MAB-063-01 2.2: Fix Distribution Distribution of critical fixes to customer sites involves five steps: installing the fix in a Critical Fix Library; announcing availability of the critical fix to Site SAs; transmitting the fix to the customer site; installing the fix at the customer site; and updating associated TRs to refer to the critical fix. 2.2.1: INSTALLING THE FIX The Critical Fix Coordinator is the person in the Multics Software Support (MSS) Unit who is responsible for installing changes in the Critical Fix Library. In general, the coordinator also has MDC responsibility for supporting U.S. Multics Sites. 2.2.1.1: Critical Fix Library The Critical Fix Library is a hierarchy of directories, grouped by release and by fix number. The critical fix for each release is placed in a separate directory for ease of access, and to avoid confusion over the various versions of a fix. ______________ / \ < >udd>sm>fixes > \______________/ | _________________________|____________________________ ... | | | | _______|_______ ______|______ _______|________ ___|__ | fixes.forum | | cfix ec's | /restricted_fixes\ / \ _______________ _____________ < directory > < MR10.0 > \________________/ \______/ The library is structured as shown above, with the Critical_Fixes forum and exec_coms used to maintain the library in the library root directory, and subdirectories to hold data security fixes (restricted_fixes) and nonsecurity fixes on a per_release basis (eg, an MR10.0 fixes directory, one for MR10.2, for MR10.2, etc). create_release_dir.ec can be used to create a fix directory for a new release. It creates the directory and sets ACLs and initial ACLs properly. 2.2.1.2: Critical Fix Directory Within each release directory, each fix is stored in a subdirectory. In cases where the same fix applies to several releases, a fix subdirectory is placed in the newest release - 21 - MAB-063-01 Critical Fixes directory, and links to this subdirectory are placed in the other release directories to which the fix applies. ______________ / \ < >udd>sm>fixes > \______________/ | ... __________________________|_____________________ ___|__ __|___ ___|__ / \ / \ / \ < MR10.0 > < MR10.1 > < MR10.2 > \______/ \______/ \______/ | | | _____|_____ _____|____ _____|____ | | | | | | __|_ ___|__ __|_ _|__ __|_ _|__ / \ [ ] / \ / \ / \ / \ [fix_65] \____/ [___.__] \____/ \____/ \____/ \____/ | A |_____________________| link A critical fix directory can be created in any given release directory by the create_fix_dir.ec. This creates the directory, sets ACLs and initial ACLs, and makes that directory the working directory. Segments required in the fix are placed the fix directory. __|___ / \ < MR10.2 > \______/ | __|___ / \ < fix_65 > \______/ | _______________|______________________________ __________|__________ __________|_________ __________|_________ | act_proc.pl1.orig | | act_proc.pl1.new | | act_proc.pl1.cpa | |___________________| |__________________| |__________________| These segments include the originally released software (act_proc.pl1.orig), the fixed version of the software (act_proc.pl1.new), and a compare_ascii output file showing the differences between the two versions (act_proc.pl1.cpa). - 22 - Critical Fixes MAB-063-01 The lib.ec and library_fetch command can be used to access original source modules in directories on the Release Logical Volume. The cpaf.ec can be used to create the compare_ascii output file. The protect_fix.ec can be used to place the IACL for segments on all segments in the fix directory and to turn on segment safety switches. The Critical Fix Coordinator is responsible for updating history | comments in all source modules that constitute a critical fix. | The history_comment command (MTB-716) must be used to update | history comments. A sample command line is: | | hcom add_field prog.pl1 -approve fix_74 -install GDixon | -vdt hcom_cfix_validate_ | | For a critical fix history comment, the operand of -approve is | the critical fix number, in the form fix_NN (or fix_NN.ds for | data security fixes). The operand of -install should be the | personid of the person installing the critical fix into the | library. | 2.2.1.3: Protecting Data Security Fixes during Installation Data security critical fixes are kept in a separate part of the library hierarchy, apart from the nonsecurity critical fixes. Security fixes are numbered using a separate numbering sequence (eg, fix_1.ds) to avoid leaving gaps in the numbers for nonsecurity fixes. - 23 - MAB-063-01 Critical Fixes ______________ / \ < >udd>sm>fixes > \______________/ | _______|________ / \ < restricted_fixes > \________________/ | ... __________________________|_____________________ ___|__ __|___ ___|__ / \ / \ / \ < MR10.0 > < MR10.1 > < MR10.2 > \______/ \______/ \______/ | | | _____|_____ _____|____ _____|____ | | | | | | __|_ ___|__ __|_ _|__ __|_ _|__ /fix_\ [ fix_ ] /fix_\ /fix_\ /fix_\ /fix_\ < 3.ds > [ 4.ds ] < 3.ds > < 4.ds > < 3.ds > < 4.ds > \____/ [___.__] \____/ \____/ \____/ \____/ | A |_____________________| link Access to the critical fix will be limited to: o the Critical Fix Coordinator; o the developer; o the Multics Security Coordinator; and o the Site Security Distributors and Foreign Affiliate Security Fix Distributors, after the fix has been approved and announced, and upon explicit request for access. Access will be granted by Person_id.Project_id ONLY. No *.Project_id ACL terms will be granted, nor *.*.* ACL terms. The fix description to be given to Site and Foreign Affiliate Security Distributors will contain only the following information: o fix number; o brief description of the symptoms (1-2 lines); o names of modules being fixed; o releases in which the problem exists; o release in which the problem will be fixed; o releases to which the critical fix applies; o pathnames of the critical fix directories; o type of testing performed for the critical fix. - 24 - Critical Fixes MAB-063-01 The fix description does not contain TR numbers or error list entries. No TRs or error list entries are created for such problems. The description should not describe the actual problem or the methods by which this problem could be exploited to bypass data security. For data security errors, the Critical Fix Coordinator prepares a description of the problem which includes: o fix number; o symptoms seen when the problem occurs; o a brief description of the problem, giving an overview of the method for exploiting security, but not a step-by-step analysis telling how to exploit the security hole; and o method of fixing the problem. This information is provided for use by the Critical Fix Coordinator in deciding whether symptoms described by a Site SA * for a problem at his site would be corrected by the data security fix. It also forms a historical record of data security problems | for use by MDC. This information will be placed in a separate | part of the Critical Fix Library: ______________ / \ < >udd>sm>fixes > \______________/ | _______|________ / \ < restricted_fixes > \________________/ | ________|__________ | ds.descriptions | |_________________| Access to the information will be restricted to: o the Critical Fix Coordinator; o the developer (to verify accuracy of the information); o the Multics Security Coordinator; and | o other MDC personnel who have a need to know this | information. | In no case will the information in these detailed descriptions be released to individuals not listed above. - 25 - MAB-063-01 Critical Fixes 2.2.2: ANNOUNCING THE FIX Separate procedures are used for announcing nonsecurity and data security critical fixes, as described in the following paragraphs. 2.2.2.1: Announcing a Nonsecurity Fix A forum transaction is entered in the Critical_Fixes forum on System M to announce that a critical fix is available for distribution to sites. The Site SA for each site is responsible for logging in to System M on a regular basis to check for the announcement of new critical fixes. The forum transaction will include: o fix title o fix number o symptoms of the problem o description of the problem o description of how the fix corrects the problem | o TR and/or error list numbers associated with the problem | o names of modules being fixed, and names of their containing | bound segments o releases in which the problem exists o release in which the problem will be corrected o releases for which a fix exists o location of the fix in the Critical Fix Library, and o type of testing performed for the fix. This transaction provides the information needed by the Site SA to determine whether the fix should be transmitted and installed at his site. 2.2.2.2: Announcing a Data Security Fix In order to reduce the possibility of someone exploiting a data security problem before sites have had time to apply the fix, a special procedure is used to announce the availability of a data | security fix. This procedure involves mailing announcements of | data security fixes to a select group of SiteSAs (known as | Security Fix Distributors), and tracking the notification, access | to and installation of such fixes in a security_fix.db MRDS | database. The database is located in a separate part of the | Critical Fix Library: - 26 - Critical Fixes MAB-063-01 ______________ | / \ | < >udd>sm>fixes > | \______________/ | | | _______|________ | / \ | < restricted_fixes > | \________________/ | | | ________|__________ | | security_fix.db | | |_________________| | | Access to this data security fix track database is restricted to: | | o the Critical Fix Coordinator; | o the Multics Security Coordinator; and | o other MDC personnel who have a need to know this | information. | 2.2.2.2.1: Contents of Mailed Announcements Mail is sent to Security Fix Distributors announcing the | availability of each data security fix. The mail contains no | information about the problem. It only announces the | availability of a data security critical fix, gives the fix number, and the Person_id of the Critical Fix Coordinator to whom the Security Fix Distributor should send his request for access. Data security critical fixes will not be announced in the Critical_Fixes forum, in order to limit knowledge of the existence of these problems. A separate sequence of numbers will be used to designate data security fixes to avoid having gaps in the numbers of nonsecurity critical fixes which are announced in the Critical_Fixes forum. The Critical Fix Coordinator uses the secfix.ec announce | operation to announce the availability of data security critical | fixes to Security Fix Distributors. This exec_com automates the | entire announcement process, insuring that the announcement is | sent via send_mail -acknowledge. When acknowledgements are | received, the secfix.ec notify operation should be used to record | that the site have been notified of availability of the fix. | 2.2.2.2.2: Site Security Fix Distributor For each U.S. site, a single Site SA is designated as the Site Security Fix Distributor. This person is the primary interface with MDC for dealing with security fixes. He is chosen by the - 27 - MAB-063-01 Critical Fixes Critical Fix Coordinator, with the advice of the primary Site SA for the site. The Critical Fix Coordinator will mail each new Site Security Fix Distributor a set of guidelines for limiting access to the information in data security fixes. Announcement of availability of a data security fix is sent to the distributor by mail requesting acknowledgment. If acknowledgment is not received within 7 days, the Critical Fix Coordinator will attempt to contact the Site Security Fix Distributor directly by telephone. To obtain a data security fix, the distributor requests access to a version of the fix for the software release running at his | site. The Critical Fix Coordinator grants access using the | gatf.ec. When access is granted, the distributor transmits the fix to his site and installs it. 2.2.2.2.3: Foreign Affiliate Security Fix Distributor For each foreign company affiliated with Honeywell Information Systems, a single member of the TAC is designated as the Foreign Affiliate Security Fix Distributor. This person is his company's primary interface with MDC for dealing with security fixes. He is chosen by the Critical Fix Coordinator, with the advice of the manager of the affiliated company's Technical Assistance Center (TAC). The Critical Fix Coordinator will mail each new Foreign Affiliate Security Fix Distributor a set of guidelines for limiting access to the information in data security fixes. These guidelines describe the distributor's responsibility to protect the information in data security fixes, to identify Site Security Fix Distributor's for his customers, and to inform these site distributors of their responsibility to protect data security fixes. Announcement of availability of a data security fix is sent to this distributor by mail requesting acknowledgment. If acknowledgment is not received within 7 days, the Critical Fix Coordinator will attempt to contact the Foreign Affiliate Security Fix Distributor directly by telephone. The distributor must request access to the versions of the fix | for releases in use at his company's customer sites. The | Critical Fix Coordinator grants access using the gatf.ec. When access is granted, the distributor transmits the fix to the Multics system which supports his TAC, and from there to his customer sites. The distributor either installs the fix at - 28 - Critical Fixes MAB-063-01 customer sites himself, or designates a Site Security Fix Distributor who installs the fix at the site. - 29 - MAB-063-01 Critical Fixes 2.2.3: TRANSMITTING CRITICAL FIXES TO THE SITE The Site SA has the responsibility for transmitting a nonsecurity critical fix to his site for installation. For data security critical fixes, the Foreign Affiliate Critical Fix Distributor and/or the Site Critical Fix Distributor have this responsibility. 2.2.3.1: Methods of Transmission In most cases, critical fixes are small in terms of the number of lines changed. There are several methods which Site SAs can use to transmit the fixes to their site. One is to log into System M on a hardcopy terminal, print the compare_ascii output files from the fix directory on their terminal, and then use that hardcopy output to modify the original source on their system by hand. For small changes, this is often the simplest and fastest method. Another alternative is to log into System M on a terminal with a recording device attached (eg, a cassette tape or PC disk drive, etc) and transfer the compare_ascii files to the recording device. The Site SA can then log into his own system, transfer the cpa output file from his recording device into the Multics hierarchy, and use a tool to produce a fixed version of the source module from the original source plus the cpa output file. Several uninstalled tools are available. One is an exec_com (cv_cpa_to_ec.ec) which changes the cpa output file to an exec_com which modifies the original (released) source module to produce a fixed source module. A third transfer method is for the Site SA to log into his system, and to use dial_out to log from there into System M. Then any of several file transfer protocols can be used to transmit either the compare_ascii output file or the modified source file from System M directly to the site. One such transfer protocol is the uninstalled dial_out_transfer command. Another less formal method is to print the cpa output file on System M while using audit or file_output to capture the printed lines at the Site SA's site. Finally, for very large critical fixes, MDC will, upon request of the SiteSA, send a tape to the site containing one or more of the critical fixes. 2.2.3.2: Protecting Data Security Fixes at the Site The Site Security Fix Distributor is responsible for preventing other individuals from accessing the fix while it is in transmission to the site and when it is stored at the site. Similarly, the Foreign Affiliate Security Fix Distributor must - 30 - Critical Fixes MAB-063-01 prevent others from accessing the fix, except for Site Security Fix Distributors supporting his company's sites. The purpose of restricting access is to limit the number of people who know about the existence of the problem. This reduces the possibility of using the problem to bypass security protection at the distributor's site or at some other site. - 31 - MAB-063-01 Critical Fixes 2.2.4: INSTALLING CRITICAL FIXES AT THE SITE The Site SA has the responsibility for installing nonsecurity critical fixes at his site. The Foreign Affiliate Security Fix Distributor and/or his Site Security Fix Distributors have the responsibility for installing data security critical fixes at | their sites. When data security fixes are installed, the | Security Fix Distributor is asked to send mail to the Critical | Fix Coordinator indicating installation of the fix. The Critical | Fix Coordinator uses the secfix.ec install operation to record | the installation in the data security fix database. Installation is performed by applying the compare_ascii changes to the original source to produce modified source; compiling the modified source; archiving the modified source and the modified object in updating archives; binding; using update_seg to install the updating archives in >special_ldd (or other directory containing site modifications). For hardcore changes, a new hardcore tape is generated using >special_ldd>hard>execution in the hardcore.search file. For online changes, the new bound segment is installed in the appropriate online execution directory. - 32 - Critical Fixes MAB-063-01 2.2.5: UPDATING TRS ASSOCIATED WITH A FIX Updating of any TRs associated with the fix is the final step in the critical fix creation and distribution process. After the critical fix has been announced, the Critical Fix Coordinator has the responsibility to add a transaction to TRs which are associated with the fix. For normal TRs, this transaction simply indicates that there is a critical fix which applies to the TR. The TR remains open pending normal submission of the fix by the developer. For high and critical TRs, the transaction can be used to resolve the high or critical nature of the TR, because it makes a fix for the problem available to the TR submitter. If the developer is tracking the problem through an error list and doesn't object to the TR being closed, then the Critical Fix Coordinator's transaction should resolve the TR by marking it submitted, referring to the critical fix as the method of resolution. If the developer prefers to leave the TR open, then the coordinator should split the TR into two TRs: the original assigned to the developer whose priority is reduced to normal and which remains open (in a responded stage); and a copy which remains at high or critical priority, but which is resolved by the critical fix. The process_trouble_report (ptr) command's split_tr request can be used to perform the splitting. Transactions should be added to both the original and the copy referring to the critical fix. - 33 - MAB-063-01 Critical Fixes APPENDIX A: TOOLS FOR CRITICAL FIXES This appendix describes the exec_coms used to create critical fixes and to maintain the Critical Fix Library. All exec_coms reside in the root directory of the Critical Fix Library, >udd>sm>fixes. - 34 - _______ _______ cpaf.ec cpaf.ec _______ _______ Name: cpaf.ec SYNTAX AS A COMMAND: ec cpaf original_segment fixed_segment cpa_args FUNCTION: The cpaf exec_com uses compare_ascii to compare an original segment shipped with a Multics Release with a fixed version of that segment. The output is appended to the compilation listing file for the fixed segment, if one exists (ie, [strip fixed_segment].list); or is placed in a new file, [strip_entry fixed_segment].cpa in the working directory. ARGUMENTS: original_segment is the pathname of the original source segment shipped with the Multics Release. The star convention is not allowed. fixed_segment is the pathname of the fixed version of the source segment to be compared with the original version. The equals convention is allowed. EXAMPLES: ec cpaf act_proc.pl1.orig ==.new compares the segment act_proc.pl1.orig with act_proc.pl1.new in the working directory. Assuming there is no act_proc.pl1.list in that directory, the compare ascii output is placed in act_proc.pl1.cpa. DRAFT: MAY BE CHANGED 35 08/13/85 __________________________ __________________________ create_fix_dir.ec (cfd.ec) create_fix_dir.ec (cfd.ec) __________________________ __________________________ Name: create_fix_dir.ec (cfd.ec) SYNTAX AS A COMMAND: ec cfd release fix FUNCTION: Creates a directory in the Critical Fix Library to hold the version of a critical fix for a given release. This exec_com must be run several times to create directories for fixes which apply to several releases. If fix versions for two releases are the same, then use the create_fix_link.ec to create a fix link for the earlier release, and use create_fix_dir.ec for the later release. ARGUMENTS: release gives the Multics Release number (eg, 10.1) to which this version of the critical fix applies. fix gives the critical fix number of the directory to be created. If you are creating a new fix, the next_fix_number.ec can be used to determine what the new fix number should be. Fix numbers may be given in two forms: a number (eg 80) for nonsecurity fixes; number.ds (eg, 4.ds) for data security fixes. NOTES: This command creates the specified fix directory, makes it the working directory, sets the ACL and IACL for segments on the directory, turns on its safety switch, and for a new fix, copies a template announcement into the directory. EXAMPLES: ec cfd 10.2 [ec nfn] creates a fix directory for a brand new fix in the MR10.2 release directory of the Critical Fix Library. ec cfd 10.1 80 creates an MR10.1 fix directory for critical fix 80. DRAFT: MAY BE CHANGED 36 08/13/85 __________________________ __________________________ create_fix_dir.ec (cfd.ec) create_fix_dir.ec (cfd.ec) __________________________ __________________________ ec cfd 10.2 [ec nfn r] creates a fix directory for a brand new data security fix in the MR10.2 restricted fixes directory. ec cfd 10.1 3.ds creates an MR10.1 fix directory for data security critical fix 3.ds. DRAFT: MAY BE CHANGED 37 08/13/85 ___________________________ ___________________________ create_fix_link.ec (cfl.ec) create_fix_link.ec (cfl.ec) ___________________________ ___________________________ Name: create_fix_link.ec (cfl.ec) SYNTAX AS A COMMAND: ec cfl release_with_dir fix linked_release FUNCTION: When the same critical fix version can be used for two releases, the fix version should be placed in a directory for the newer release, using the create_fix_dir.ec. This exec_com should be used create a link for the older release which points to the new release's fix directory. ARGUMENTS: release_with_dir gives the Multics Release number (eg, 10.1) for the newer release's fix directory. This directory must already exist. fix gives the critical fix number of the problem being fixed. Fix numbers may be given in two forms: a number (eg 80) for nonsecurity fixes; number.ds (eg, 4.ds) for data security fixes. linked_release gives the number (eg, 10.0) of the release directory in which a link to the newer release's fix directory should be placed. NOTES: This command creates the specified fix link, after checking that the target fix directory for the link actually exists. EXAMPLES: ec cfl 10.1 65 10.0 creates a fix link in the MR10.0 release directory for critical fix 65. The link target is fix 65's fix directory in the MR10.1 release directory. DRAFT: MAY BE CHANGED 38 08/13/85 ___________________________ ___________________________ create_fix_link.ec (cfl.ec) create_fix_link.ec (cfl.ec) ___________________________ ___________________________ ec cfl 10.1 4.ds 10.0 creates a fix link in the MR10.0 release directory for data security fix 4.ds. The link target is the 4.ds fix directory in the MR10.1 restricted fixes release directory. DRAFT: MAY BE CHANGED 39 08/13/85 ______________________________ ______________________________ create_release_dir.ec (crd.ec) create_release_dir.ec (crd.ec) ______________________________ ______________________________ Name: create_release_dir.ec (crd.ec) SYNTAX AS A COMMAND: ec crd release {restricted} FUNCTION: Creates a new Multics Release directory in the Critical Fix Library to hold versions of critical fixes for the given Multics Release. ARGUMENTS: release gives the Multics Release number (eg, 10.1) whose release directory is to be created. restricted is an optional argument which can be the word "restricted" or "r", to indicate that the release directory is to be created in the restricted_fixes portion of the Critical Fix Library. The default is to create the release directory in the nonsecurity fix portion of the library. NOTES: This command creates the specified fix directory, sets the ACL and IACL for segment and directories on the directory, and turns on its safety switch. EXAMPLES: ec crd 10.2 creates a new Multics Release directory in Critical Fix Library to hold fixes for the MR10.2 release. ec crd 11 r creates an MR11 release directory to hold data security critical fixes. DRAFT: MAY BE CHANGED 40 08/13/85 _________________________ _________________________ cv_cpa_to_ec.ec (ccte.ec) cv_cpa_to_ec.ec (ccte.ec) _________________________ _________________________ Name: cv_cpa_to_ec.ec (ccte.ec) SYNTAX AS A COMMAND: ec ccte cpa_output ec cpa_output original_source modified_source FUNCTION: The ccte exec_com converts a segment containing compare_ascii output into an exec_com. The exec_com is created in the working directory, in a segment named [strip_entry cpa_output cpa].ec. When the exec_com is run against the original source (the A source) given in the compare_ascii output file, it will produce the modified source (the B source). ARGUMENTS: cpa_output is the pathname of a file containing compare_ascii output. If it ends with a suffix of cpa, this suffix is removed when constructing the name of the output exec_com file. Otherwise, the output pathname is constructed by adding a suffix of ec to cpa_output. original_source is the pathname of the original source program (the A source) which was used to produce the compare_ascii output file. modified_source is the pathname of a file to be created by modifying the original source program according to the changes in the compare_ascii output (thus producing the B source from the compare_ascii output). EXAMPLES: The example below is a script which shows how a modified source module can be created from a compare_ascii output file for critical fix 65. The example uses several other tools besides the cv_cpa_to_ec.ec exec_com. Please refer to the documentation for these other tools for details of their operation. DRAFT: MAY BE CHANGED 41 08/13/85 _________________________ _________________________ cv_cpa_to_ec.ec (ccte.ec) cv_cpa_to_ec.ec (ccte.ec) _________________________ _________________________ ! ec cwdf 10.2 65 Working_dir = >udd>sm>fixes>MR10.2>fix_65 changes to the MR10.2 fix directory for critical fix 65. ! ls lists the contents of the fix directory. Segments = 3, Lengths = 15. r 1 act_proc.pl1.cpa r 7 act_proc.pl1.new r 7 act_proc.pl1.orig ! ec lib 10.2 addresses the MR10.2 Libraries Release attached via library descriptor. mr10_2_libraries_ ! cd x creates and changes to a ! cwd x subdirectory of the fix dir. ! ec [ec cwdf]>ccte udd>sm>fixes), or a directory which is not part of Critical Fix Library. It is frequently necessary to move from one fix directory to another, related fix directory in the library. The exec_com facilitates such moves by changing to a directory which DRAFT: MAY BE CHANGED 44 08/13/85 ____________________ ____________________ cwd_fix.ec (cwdf.ec) cwd_fix.ec (cwdf.ec) ____________________ ____________________ is related to the working directory. The examples below illustrate this behavior. EXAMPLES: ! wd >udd>Multics>GDixon ! ec cwdf Working_dir = >udd>sm>fixes ! string [ec cwdf r] >udd>sm>fixes>rf ! wd >udd>sm>fixes ! ec cwdf 10.2 80 Working_dir = >udd>sm>fixes>MR10.2>fix_80 ! ec cwdf 10.1 Working_dir = >udd>sm>fixes>MR10.1>fix_80 ! ec cwdf 10.0 Unable to find a directory matching: ec cwdf 10.0 ! ec cwdf 10.2 Working_dir = >udd>sm>fixes>MR10.2>fix_80 ! ec cwdf 79 Working_dir = >udd>sm>fixes>MR10.2>fix_79 ! ec cwdf 78 Working_dir = >udd>sm>fixes>MR10.2>fix_78 ! ec cwdf 10.2 1.ds Working_dir = >udd>sm>fixes>rf>MR10.2>fix_1.ds ! ec cwdf 10.1 Working_dir = >udd>sm>fixes>rf>MR10.1>fix_1.ds ! ec cwdf 2.ds Working_dir = >udd>sm>fixes>rf>MR10.1>fix_2.ds ! ec cwdf r Working_dir = >udd>sm>fixes>rf DRAFT: MAY BE CHANGED 45 08/13/85 ____________________ ____________________ cwd_fix.ec (cwdf.ec) cwd_fix.ec (cwdf.ec) ____________________ ____________________ ! ec cwdf 10.2 Working_dir = >udd>sm>fixes>MR10.2 ! ec cwdf 10.2 r Working_dir = >udd>sm>fixes>rf>MR10.2 ! ec cwdf Working_dir = >udd>sm>fixes DRAFT: MAY BE CHANGED 46 08/13/85 ___________________________ ___________________________ give_access_to_all_fixes.ec give_access_to_all_fixes.ec ___________________________ ___________________________ Name: give_access_to_all_fixes.ec SYNTAX AS A COMMAND: ec gataf user_ids FUNCTION: The gataf exec_com gives a new set of users or projects permanent access to all nonsecurity critical fixes. ARGUMENTS: user_ids are the user_ids to whom read access is to be granted. EXAMPLES: ec gataf Fakoury.Tolts gives Fakoury.Tolts.* read access to all existing nonsecurity critical fixes, and places him in the IACLs so that he will have access to future fixes which are created. DRAFT: MAY BE CHANGED 47 08/13/85 _______________________________ _______________________________ give_access_to_fix.ec (gatf.ec) give_access_to_fix.ec (gatf.ec) _______________________________ _______________________________ Name: give_access_to_fix.ec (gatf.ec) SYNTAX AS A COMMAND: | ec gatf releases fix person.project {restrict} {record} FUNCTION: The gatf exec_com gives a SiteSA or Multics developer access to the segments in a data security critical fix. It also attempts to record granting of such access in the security fix MRDS tracking database. ARGUMENTS: releases gives the name or names of Multics Releases in the Critical Fix Library for which access to the given fix is to be granted. A single release number can be given (eg, 10.1), or several release numbers can be given as a quoted string (eg, "10.0 10.1 10.2"). The multi-release form is useful in doing cross-product iteration when granting access to several release versions of several fixes. See "Examples" below. fix gives the number of the critical fix (eg, 3.ds) to which access is to be granted. person.project is the user_id to whom access is to be granted. Both a person_id and project_id must be given. Access will be granted to this user_id, and mail will be sent to the user notifying him of what access has been set. | restrict | indicates whether the fix is a restricted fix or a normal fix. | Restricted fixes are those in the | >udd>sm>fixes>restricted_fixes hierarchy whose fix numbers do | not include the .ds suffix (eg >udd>sm>fixes>rf>fix_71). The | restrict argument can have values of restricted (r) and normal | (n). The default is normal. DRAFT: MAY BE CHANGED 48 08/13/85 _______________________________ _______________________________ give_access_to_fix.ec (gatf.ec) give_access_to_fix.ec (gatf.ec) _______________________________ _______________________________ record | controls whether granting access to data security critical | fixes is records in the MRDS tracking DB. Since the database | only includes records for sites and SiteSAs, giving developers | access to data security fixes cannot be recorded in the | database. Values can be record (rec) or no_record (nrec). | The default is record if the fix number indicates a data | security fix, and no_record otherwise. | EXAMPLES: ec gatf 10.2 1.ds Auerbach.SiteSA gives Auerbach.SiteSA.* read access to the 10.2 version of data security critical fix 1.ds, and sends him mail to that effect. ec gatf "10.0 10.1 10.2" (3 4).ds Burnham.SiteSA gives Burnham.SiteSA access to the 10.0, 10.1 and 10.2 versions of critical fixes 3.ds and 4.ds. This is cross-product iteration, in which access is granted for all combinations of release and fix number. DRAFT: MAY BE CHANGED 49 08/13/85 ______ ______ lib.ec lib.ec ______ ______ Name: lib.ec SYNTAX AS A COMMAND: ec lib release SYNTAX AS AN ACTIVE FUNCTION: [ec lib release] FUNCTION: The lib exec_com attaches the Release logical volume to the user's process (if it is not already attached). When invoked as a command, it then changes the default library descriptor to reference the Multics Libraries for the given release. The library descriptor commands such as library_fetch, library_pathname, and library_info can be used to access segments in the given release library. When invoked as an active function, the exec_com returns the pathname of the library descriptor for the Multics Libraries of the given release. This pathname can be used with the -descriptor control argument in one of the library descriptor commands to access segments in the library. ARGUMENTS: release is the release number of the Multics Libraries to be accessed. Numbers are given in the form: 10.1 EXAMPLES: ! ec lib 10.1 Release attached mr10_2_libraries_ ! library_fetch act_proc.pl1 -into ===.orig -lg Library archive component act_proc.pl1 fetched from >rel>mr10.1>ldd>hard>s>bound_process_creation.s.archive into >udd>sm>fixes>10.1>fix_65>act_proc.pl1.orig ! library_pathname act_proc.pl1 -descriptor [ec lib 10.0] >rel>10.0>ldd>hard>s>bound_process_creation.s::act_proc.pl1 DRAFT: MAY BE CHANGED 50 08/13/85 ______ ______ lib.ec lib.ec ______ ______ ! cpa [lpn act_proc.pl1 -descriptor ([ec lib 10.(0 1)])] -he A >rel>10.0>ldd>hard>s>bound_process_creation.s::act_proc.pl1 B >rel>10.1>ldd>hard>s>bound_process_creation.s::act_proc.pl1 Segments are identical. DRAFT: MAY BE CHANGED 51 08/13/85 _______ _______ ^lib.ec ^lib.ec _______ _______ Name: ^lib.ec SYNTAX AS A COMMAND: ec ^lib SYNTAX AS AN ACTIVE FUNCTION: [ec ^lib] FUNCTION: The ^lib exec_com, when invoked as a command, detaches the Release logical volume (if it is attached) and restores the default library descriptor to its normal value, describing the current Multics Libraries on System M. When invoked as an active function, it returns the pathname of the library descriptor for the current Multics Libraries on System M. EXAMPLES: ! ec ^lib multics_libraries_ DRAFT: MAY BE CHANGED 52 08/13/85 ___________________________ ___________________________ next_fix_number.ec (nfn.ec) next_fix_number.ec (nfn.ec) ___________________________ ___________________________ Name: next_fix_number.ec (nfn.ec) SYNTAX AS AN ACTIVE FUNCTION: [ec nfn {restricted}] SYNTAX AS A COMMAND: ec nfn {restricted} FUNCTION: The nfn exec_com returns or prints the next number in sequence which can be used for a nonsecurity or data security critical fix. ARGUMENTS: restricted can be the word "restricted" or "r", to request the next number for a data security fix. The default is to return the next number for a nonsecurity critical fix. EXAMPLES: ! string [ec nfn] 81 ! string [ec nfn r] 5.ds DRAFT: MAY BE CHANGED 53 08/13/85 ______________________ ______________________ protect_fix.ec (pf.ec) protect_fix.ec (pf.ec) ______________________ ______________________ Name: protect_fix.ec (pf.ec) SYNTAX AS A COMMAND: ec pf FUNCTION: The pf exec_com, when invoked in a critical fix directory such as >udd>sm>fixes>10.2>fix_65, turns on the safety switch for all segments in the fix directory, and sets their ACL to value of the IACL for segments of the fix directory. NOTES: The working directory must be one of the fix directories in the Critical Fixes Library. DRAFT: MAY BE CHANGED 54 08/13/85 _________ _________ secfix.ec secfix.ec _________ _________ Name: secfix.ec | | | SYNTAX AS A COMMAND: | | ec secfix operation {args} | or: ec secfix -help | | | FUNCTION: Controls a MRDS data base defining which Multics sites | have installed data security critical fixes. | | | ARGUMENTS: | | operation | designates the operation to be performed. See "List of | Operations" below. For a detailed description of each | operation type: | | help secfix.OPERATION | | where OPERATION is the name of the specific operation. | | | CONTROL ARGUMENTS: | | -help | lists the usage line for the secfix exec_com. | | | LIST OF OPERATIONS | | notify, nt | marks site entry as having been notified that a given critical | fix is available for installation. This operation is | performed by the person who installed and announced the fix | when the SiteSA reads the mail announcing availability of the | fix, and an sends an acknowledgment to the installer. | | access, ac | marks site entry as having been given access to a given | critical fix. This operation is performed automatically by | the give_access_to_fix.ec when the installer gives the SiteSA | access to the fix. | DRAFT: MAY BE CHANGED 55 08/13/85 _________ _________ secfix.ec secfix.ec _________ _________ | install, i | marks site entry as having installed a given critical fix. | This operation is performed when the site sends mail to the | installer announcing that it has installed the critical fix. | | report, rpt | builds a formatted report containing Multics sites grouped by | type detailing all fixes and the status of each fix at each | site. | | status, st | outputs, to the tty, a formatted report giving status of fixes | for a specified site, or list of sites having an entry for a | specified fix. | | guidelines, gl | mails Security Fix Distributor guidelines to the specified | mailing addresses. These guidelines should be sent to each | new Site Security Fix Distributor and Foreign Affiliate | Security Fix Distributor. | | announce, ann | mails an announcement of the availability of a data security | fix to all existing Security Fix Distributors. | | | OPERATION: ACCESS, AC | | | SYNTAX AS A COMMAND: | | ec secfix ac site fix_number | or: ec secfix ac distributor fix_number | or: ec secfix ac -help | | | FUNCTION: marks site (or the site associated with the named | distributor) as having access to critical fix denoted by | fix_number. | | | ARGUMENTS: | | access, ac | indicates access operation. | | site | Multics site which has accessed a security fix. DRAFT: MAY BE CHANGED 56 08/13/85 _________ _________ secfix.ec secfix.ec _________ _________ distributor | selects the Multics site associated with the named fix | distributor. | | fix_number | unique identifier of a security fix. (eg, 3.ds) | | | CONTROL ARGUMENTS: | | -help | lists the usage for the access operation. | | | ACCESS REQUIRED: | | sma on directory containing the security_fix.db. | rw on the multisegment file security_fix.db | | | OPERATIONS: ANNOUNCE, ANN | | | SYNTAX AS A COMMAND: | | ec secfix ann {fix_number {developer_mailing_addresses}} | | | FUNCTION: prepares an announcement of the availability of the | given data security critical fix, and mails it to add Security | Fix Distributors, plus the developers responsible for creating | the fix. | | | ARGUMENTS: | | announce, ann | is a keyword to invoke the announce mailing operation. | | fix_number | is the number data security fix to be announced (eg, 7.ds). | (default: prompt for the fix number) | | developer_mailing_addresses | are mailing addresses of developers who are to be mailed the | announcement. (default: prompt for developers.) | DRAFT: MAY BE CHANGED 57 08/13/85 _________ _________ secfix.ec secfix.ec _________ _________ | NOTES: | | The fix number is validated. A list of releases for which the | fix exists is automatically placed in the mail. The user is | queried before sending the mail to be sure it is correct. The | mail is sent with acknowledgment. | | | OPERATION: GUIDELINES, GL | | | SYNTAX AS A COMMAND: | | ec secfix gl mailing_addresses | or: ec secfix gl -help | | | FUNCTION: mails the Guidelines for Security Fix Distributors to | the individuals whose mailing addresses are given. | | | ARGUMENTS: | | guidelines, gl | is a keyword to invoke the guideline mailing operation. | | mailing_address | is a Mail System mailing address. | | | CONTROL ARGUMENTS: | | -help | gives usage information for the guidelines operation. | | | OPERATION: INSTALL, I | | | SYNTAX AS A COMMAND: | | ec secfix i site fix_number | or: ec secfix i distributor fix_number | or: ec secfix i -help | | | FUNCTION: marks site (or site associated with a given fix | distributor) as having installed a given critical fix. DRAFT: MAY BE CHANGED 58 08/13/85 _________ _________ secfix.ec secfix.ec _________ _________ ARGUMENTS: | | install, i | indicates install operation. | | site | Multics site which having installed the specified security | fix. | | distributor | selects the Multics site associated with the named fix | distributor. | | fix_number | unique identifier of the security fix of which the site has | been installed. (eg, 3.ds) | | | CONTROL ARGUMENTS: | | -help | lists the usage line for the notify operation. | | | ACCESS REQUIRED: | | sma on the directory containing security_fix.db | rw on the multisegment file security_fix.db | | | OPERATION: NOTIFY, NT | | | SYNTAX AS A COMMAND: | | ec secfix nt site fix_number | or: ec secfix nt distributor fix_number | or: ec secfix nt -help | | | FUNCTION: marks site (or site associated with a given fix | distributor) as having been notified that a given critical fix is | available for installation. | | | ARGUMENTS: | | notify, nt | indicates notify operation. | DRAFT: MAY BE CHANGED 59 08/13/85 _________ _________ secfix.ec secfix.ec _________ _________ | site | Multics site which has been notified of the specified security | fix. | | distributor | selects the Multics site associated with the named fix | distributor. | | fix_number | unique identifier of the security fix of which the site has | been notified. (eg, 3.ds) | | | CONTROL ARGUMENTS: | | -help | lists the usage line for the notify operation. | | | ACCESS REQUIRED: | | sma on the directory containing security_fix.db | rw on the multisegment file security_fix.db | | | OPERATION: REPORT, RPT | | | SYNTAX AS A COMMAND: | | ec secfix rpt {-help} | | | FUNCTION: Creates an output segment containing a formatted | report of site and security fix status. The report is grouped by | site type and lists all fixes associated with each site. | | | ARGUMENTS: | | report, rpt | indicates the report operation. | | | CONTROL ARGUMENTS: | | -help | lists the usage line for the report operation. DRAFT: MAY BE CHANGED 60 08/13/85 _________ _________ secfix.ec secfix.ec _________ _________ ACCESS REQUIRED: | | s on the directory containing security_fix.db | r on the multisegment file security_fix.db | | | NOTES: | | The output segment is named secfix.report and is placed in the | working directory. | | | OPERATION: STATUS, ST | | | SYNTAX AS A COMMAND: | | ec secfix st site {-control_arg} | or: ec secfix st fix_number {-control_arg} | or: ec secfix st -help | | | FUNCTION: Extracts and displays all information from the | security_fix.db pertaining to an individual site or fix. | | | ARGUMENTS: | | status, st | indicates site status operation. | | site | specified identification of a Multics installation. | | fix_number | unique identifier of a security fix. (eg, 3.ds) | | | CONTROL ARGUMENTS: | | -long, -lg | prints status with all available information. (default for | status of a given site) | | -brief, -bf | prints status with only site number and implementation status. | (default for status of a given fix) | DRAFT: MAY BE CHANGED 61 08/13/85 _________ _________ secfix.ec secfix.ec _________ _________ | -help | lists the usage line for the site status operation. | | | ACCESS REQUIRED: | | s on the directory containing security_fix.db | r on the multisegment file security_fix.db DRAFT: MAY BE CHANGED 62 08/13/85 Critical Fixes MAB-063-01 APPENDIX B: GUIDELINES FOR SECURITY FIX DISTRIBUTORS After the Critical Fix Coordinator selects a Site Security Fix Distributor or Foreign Affiliate Security Fix Distributor, he will send this new distributor the following mail outlining procedures for handling data security fixes. From: Critical Fix Coordinator To: Security Fix Distributors Subject: Procedures for Data Security Critical Fixes The purpose of this letter is to announce a procedure for distributing security fixes to US sites and to foreign support personnel for further distribution to foreign sites. We recommend that each site apply these fixes as soon as possible. In order to reduce the possibility of someone exploiting the security problems before sites have had time to apply the fixes, we are restricting access to the fixes to one person per US site (the Site Security Fix Distributor), and for affiliated companies, one person per company (the Foreign Affiliate Security Fix Distributor). This distributor will be given access to the fixes. He will have sole responsibility for transmitting security fixes to the site or sites he represents, for protecting information in the fixes from disclosure at the site, and for installing the fixes at the site. When fixes are at a customer site, the distributor must limit access to the fix itself or information about the fix only to those having a need to know about the existence and nature of the critical fix. Installation of the fix should not be announced at the customer site, unless this is absolutely necessary. When a new data security fix is announced, mail will be sent on System M to each distributor indicating the location of the fix. By return mail, the distributor should send confirmation when the fix has been installed at his site (or sites). This will allow tracking of sites which have received the fix, and which have applied it. If you need assistance in applying the fixes, contact GDixon on System M by mail or telephone (602/249-6772). Please note that the information about a given fix does NOT include information about the problem itself. It only includes a two line description of possible symptoms which could be caused by the problem, plus the fixed module itself. We do not plan to release the detailed information about how these DRAFT: MAY BE CHANGED 63 08/13/85 MAB-063-01 Critical Fixes problems could be exploited to break security; this is to provide as much protection as possible to all of our sites. DRAFT: MAY BE CHANGED 64 08/13/85