Multics Technical Bulletin MTB-662 B2 Security To: Distribution From: Pozzo, Margulies Date: 07/02/84 Subject: A B2 Security Evaluation for Multics - Revised _1 _A_B_S_T_R_A_C_T This documents the current status of the Multics Security Evaluation. Section 2 describes the evaluation process with some notes about the Department of Defense Trusted Computer System Evaluation Criteria (The Criteria). Sections 3 and 4 are devoted to Multics functional deficiencies found by the team and Honeywell's response to these deficiencies. Section 5 details the schedule for implementing the changes required to cover the deficiencies. This MTB, in addition to informing the Multics community of its contents, serves as a formal response to the DOD Security Evaluation Team, informing them of Honeywell's plans for resolution of the deficiencies found by the team. Comments should be sent to the author: via Multics Mail: Pozzo.Multics on either MIT Multics or System M. via US Mail: Maria M. Pozzo Honeywell Information Systems, inc. 575 Tech Square Cambridge, Massachusetts 02139 via telephone: (HVN) 261-9364, or (617) 492-9364 _________________________________________________________________ Multics project internal working documentation. Not to be reproduced or distributed outside the Multics project without the consent of the author or the author's management. Page 1. MTB-662 Multics Technical Bulletin B2 Security _2 _T_H_E _E_V_A_L_U_A_T_I_O_N _P_R_O_C_E_S_S The DoD's intent is to make it possible for computer users inside and outside of the DoD to specify the level of security that they need, and to find systems that satisfy those specifications with "on-the-shelf" products of vendors. To that end, they have published the Criteria, and established an evaluation process. _2_._1 _T_h_e _C_r_i_t_e_r_i_a The Criteria describe four broad classes of computer systems. The first, "D", is reserved for those systems that do not meet even mimimal requirements for secure computer systems. These are effectively unsecured systems. The second, "C", requires discressionary and password access controls. The third, "B", includes all of the requirements for "C", and adds requirements for nondiscressionary control and modularization of implementation. The last, "A", requires that formal mathematical models be used to prove the accordance of the design to the security policy. The "B" class is in turn split into three levels, B1, B2, B3. Readers interested in the differences between them are referred to the Criteria. Multics is thought to be best described as a B2 system. However, there are a number of problem areas that, if left uncorrected, would leave it in the "C" class. _2_._2 _T_h_e _E_v_a_l_u_a_t_i_o_n _P_r_o_c_e_s_s The evaluation process of a system involves several phases. It is first necessary to examine the documentation and determine where the system, as documented, conforms to the levels of the Criteria. It is then necessary to test whether the system conforms functionally to its documentation. The final step is to evaluate the system with respect to penetration resistance and covert channels. The Criteria requires that the vendor demonstrate adequate controls over system changes encompassing source and object libraries, test suites and documentation. This "configuration management strategy" is necessary to assure future releases of the system meet the rated level. _________________________________________________________________ Order number CSC-STD-001-83, often referred to as the "Orange Book." Page 2. Multics Technical Bulletin MTB-662 B2 Security The evaluation process is not yet complete. The Center has not yet decided how to manage re-certification of new system releases. It is clear, however, that the requirements for a configuration management strategy, particularly those for functional testing and documentation, have been chosen with an eye toward minimizing the effort required for re-certification. _2_._3 _T_h_e _S_c_h_e_d_u_l_e At this writing, the evaluation team is in the penetration testing phase and anticipate completion within the next several weeks. The schedule for the remainder of the evaluation is uncertain as of this writing. However, it is currently intended to make the B2 rating apply to MR11. Thus, any code and documentation changes described here are intended for an MR11 shipment. _3 _M_U_L_T_I_C_S _D_E_F_I_C_I_E_N_C_I_E_S This section lists the functional deficiencies of Multics as determined by the evaluation team after a thorough examination of available documentation. The later parts of the evaluation process (functional testing and penetration testing) may uncover additional system weaknesses and bugs. This section is subsectioned in parallel with the Orange Book, for ease of reference. Each section begins with the Evaluation Team's reported deficiency, and continues with explanatory comments. Sections of the Orange Book where Multics satisfies the Criteria are not mentioned. _3_._1 _E_x_p_o_r_t_a_t_i_o_n _o_f _L_a_b_e_l_e_d _I_n_f_o_r_m_a_t_i_o_n _(_3_._2_._1_._3_._2_, _p_a_g_e _2_7_) Although the creation of multi-class tapes is supported, the tapes cannot be used unless rcp_priv is turned on in the accessing process or the process is running in ring-1. RCPRM, the part of the TCB which controls devices, does not audit changes in the AIM classification of volumes and devices. See Section 4.6 Audit. _3_._2 _L_a_b_e_l_i_n_g _H_u_m_a_n_-_R_e_a_d_a_b_l_e _O_u_t_p_u_t _(_3_._2_._1_._3_._2_._3_, _p_a_g_e _2_8_) The AIM classification of the file printed is marked on top and bottom of page. The IO Daemon allows users to over-ride this marking but does not audit this event. Page 3. MTB-662 Multics Technical Bulletin B2 Security _3_._3 _D_e_v_i_c_e _L_a_b_e_l_s _(_3_._2_._1_._3_._4_, _p_a_g_e _2_8_) Communications channels do not have both minimum and maximum AIM classifications. _3_._4 _I_d_e_n_t_i_f_i_c_a_t_i_o_n _a_n_d _A_u_t_h_e_n_t_i_c_a_t_i_o_n _(_3_._2_._2_._1_, _p_a_g_e _2_9_) All users connected to the system must be identified (via a user-id) and authenticated (via a password). This verification must be performed by the system mechanism designed for that purpose. Multics is deficient in two ways. First, dial and slave pre-access commands do not allow an access class to be specified as is the case with login. Second, operators are not identified or authenticated in any way. The check_acs feature does force a user name and password for dial and slave requests but does not associate an authenticated name with future actions. In addition, it does not compare the default/maximum authorization of the user name supplied in the PNT against the channel and the process attaching the channel. When not in admin mode, no name/password is solicited from the operator. In addition, the PNT is located in ring-4, increasing the risk of compromise. See Section 3.6 Audit. _3_._5 _T_r_u_s_t_e_d _P_a_t_h _(_3_._2_._2_._1_._1_, _p_a_g_e _2_9_) The Trusted Facilities documentation must describe the importance of DTR in achieving a trusted path to the answering service. The -auth control argument of new_proc must be able to be disabled as a site option. A "Trusted Path" is a communication path to the "system" that is guaranteed to be un-cooptable by a trojan horse. A trusted path must be available for all requests for changes in access authorization, password, etc. The only trusted path currently implemented in Multics is the connection to the answering service that you get when your terminal drops DTR, and the hangup causes the Answering Service to take your line. A trojan horse could simulate new_proc (i.e., create a new process at a different authorization, without the user's knowledge), causing the user to type information into files at an inappropriate classification. The same holds true for the -hold control argument to logout. Thus, the -hold argument must also be able to be disabled as a site option. Page 4. Multics Technical Bulletin MTB-662 B2 Security _3_._6 _A_u_d_i_t _(_3_._2_._2_._2_, _p_a_g_e _2_9_) Multics fails to audit a variety of events covered by the description in the Criteria in this section. In particular, system administration and RCPRM do no useful auditing, the hardcore does not audit successful accesses, and many audit trails, particularly administrative, are incomplete. In addition, because the PNT is located in ring-4, it is impossible to audit changes to it. _3_._7 _S_y_s_t_e_m _I_n_t_e_g_r_i_t_y _(_3_._2_._3_._1_._2_, _p_a_g_e _3_0_) Honeywell has not supplied the Team with a description of T&D and related items to allow them to satisfy themselves that a site can validate the operation of the hardware and firmware. _3_._8 _C_o_v_e_r_t _C_h_a_n_n_e_l _A_n_a_l_y_s_i_s _(_3_._2_._3_._1_._3_, _p_a_g_e _3_0_) The team has not been provided with the results of a covert channel analysis. _3_._9 _T_r_u_s_t_e_d _F_a_c_i_l_i_t_i_e_s _M_a_n_a_g_e_m_e_n_t _(_3_._3_._3_._1_._4_, _p_a_g_e _3_8_) The Multics operator is "all powerful." It must be possible to prevent the operator from using security administration, or otherwise compromising the security of the system, due to access to facilities not needed to operate the system. There are two problems here. First, the restricted operator environment includes the logical volume administration commands, which (a) can be used to change the AIM restrictions on volumes, and (b) are not needed in normal operation. Second, the operator has complete control over the Dumper daemons, which (a) have access to privileged facilities, and (b) are sitting at normal Multics command level most of the time. _3_._1_0 _D_e_s_i_g_n _S_p_e_c_i_f_i_c_a_t_i_o_n _a_n_d _V_e_r_i_f_i_c_a_t_i_o_n _(_3_._3_._4_._4_, _p_a_g_e _4_0_) Honeywell has not provided the team with adequate documentation. This includes a claim that Multics implements the Bell-LaPadula security model. Page 5. MTB-662 Multics Technical Bulletin B2 Security _3_._1_1 _C_o_n_f_i_g_u_r_a_t_i_o_n _M_a_n_a_g_e_m_e_n_t _(_3_._3_._3_._2_._3_, _p_a_g_e _3_9_) Honeywell has not provided the team with a description of our configuration management strategy. _3_._1_2 _S_e_c_u_r_i_t_y _F_e_a_t_u_r_e_s _U_s_e_r_'_s _G_u_i_d_e _(_3_._3_._4_._1_, _p_a_g_e _3_9_) TR's have been submitted by AFDSC on behalf of security specifying those areas where the existing Multics documentation fails to meet the Criteria. All the security-related commands must be documented in one place; possibly with references to other documentation where more detailed information can be found. This document should identify the implications of exercising the different commands and their options with regards to security. _3_._1_3 _T_r_u_s_t_e_d _F_a_c_i_l_i_t_y _M_a_n_u_a_l _(_3_._3_._4_._2_, _p_a_g_e _3_9_) TR's have been submitted specifying those areas where the existing Multics documentation fails to meet the Criteria. Privileged commands of both operators and administrators must be documented. _3_._1_4 _T_e_s_t _D_o_c_u_m_e_n_t_a_t_i_o_n _(_3_._3_._4_._3_, _p_a_g_e _4_0_) Honeywell has not supplied the team with documentation on Functional Testing procedures. _3_._1_5 _D_e_s_i_g_n _D_o_c_u_m_e_n_t_a_t_i_o_n _(_3_._3_._4_._4_, _p_a_g_e _4_0_) Honeywell has not supplied the Evaluation Team with adequate design documentation. Readers are encouraged to read the appropriate section in the Orange Book for more information on what is required. _4 _P_R_O_P_O_S_E_D _R_E_S_P_O_N_S_E _T_O _T_H_E _D_E_F_I_C_I_E_N_C_I_E_S The deficiency list above requires a significant amount of work. Quite aside from whatever marketing requirement Honeywell may have to "make B2", most of the items are things that, in general, would be considered deficiencies. For example, it is certainly a failing of current development strategies that a complete and coherent functional test suite for important system interfaces is not maintained. Much of what is proposed here could be justified independently on "quality" grounds. Page 6. Multics Technical Bulletin MTB-662 B2 Security This section is subsectioned in parallel with section 3 "Multics Deficiencies", and details Honeywell's response to each of the items mentioned as well as changes required to the system to cover these deficiencies. _4_._1 _E_x_p_o_r_t_a_t_i_o_n _o_f _L_a_b_e_l_e_d _I_n_f_o_r_m_a_t_i_o_n Since the use of multi-class tapes is not a feature provided with the system, this is not a problem. _4_._2 _L_a_b_e_l_i_n_g _H_u_m_a_n_-_R_e_a_d_a_b_l_e _O_u_t_p_u_t The IO Daemon will be modified to disallow over-riding of page labels as the default. Since this will be site-settable, in systems where it is allowed, over-riding of page labels will be audited. _4_._3 _D_e_v_i_c_e _L_a_b_e_l_s Work on Communications Channel AIM has already begun and is detailed in a separate MTB. _4_._4 _I_d_e_n_t_i_f_i_c_a_t_i_o_n _a_n_d _A_u_t_h_e_n_t_i_c_a_t_i_o_n Much of this work falls under the work being done for Communications Channel AIM. In addition, the PNT will be moved to ring-1. Furthermore, modifications will be made to require identification and authentication of operators. _4_._5 _T_r_u_s_t_e_d _P_a_t_h As the default, new_proc -auth and logout -hold will be disabled. This will be a site-settable parameter. _4_._6 _A_u_d_i_t_i_n_g _-_- _N_e_w _L_o_g_g_i_n_g _F_a_c_i_l_i_t_i_e_s The Criteria require that many more events be audited than is currently audited. Existing mechanisms for auditing (the Syserr log and the Answering Service log) cannot handle the additional load and provide reasonable performance. A better logging system needs to be designed and implemented. In the long run, the new mechanism should supersede the existing mechanisms so that all messages are handled consistently. In the short run, however, it is feasible to replace only the syserr log with the new mechanism Page 7. MTB-662 Multics Technical Bulletin B2 Security while leaving the Answering Service log alone. A future MTB will discuss these issues in more detail. 4.6.1 AUDITING -- NEW THINGS TO AUDIT This subsection describes some of the more important areas where new auditing is to be added. In general, an examination of the system, adding audit trails where appropriate, must be completed. 4.6.1.1 Successful Accesses Hardcore only audits access violations. The Criteria require auditing successful accesses. This implies audit of each make-known, make-unknown and of any activation that changes the access available in the SDW. It also requires audit of directory control operations, such as appends, deletes, ring changes and acl changes. In addition, a site must be able to set an audit threshold for levels or categories for both persons and projects. This feature will be added. 4.6.1.2 RCPRM Access Decisions RCPRM has the opposite problem. It leaves behind a syserr message each time a resource is reserved, assigned, attached, detached, unassigned, or unreserved, but leaves no record of access refusals. The audit trails that it does leave contain no access information. This is a bigger problem than it looks. The code structure of RCPRM makes all the real access decisions in a module that has limited knowledge of what operation is taking place. The calling modules that know what is going on do not know why the access was denied, only that the user lacked sufficient effective access. This requires more than just adding audit messages to modules. The interface to the program that evaluates effective access must be changed so that enough information is available to generate the audit trail. 4.6.1.3 Administration There is no auditing of security-related administration. For PDT and SAT AIM fields, the audit trail of the table installation does exist. It does not indicate what was done, but at least it identifies the doer. For the PNT, even that is missing. The PNT will have to be moved to an inner ring so that changes to it can be audited (see Identification and Authentication, Section 4.4). Page 8. Multics Technical Bulletin MTB-662 B2 Security _4_._7 _S_y_s_t_e_m _I_n_t_e_g_r_i_t_y Honeywell will provide the team with statements of confidence that assure the correct functioning of the CPU/SCU, IOM, IO Devices, MPC and the FNP. Honeywell will be receiving a list from the team of what the statements of confidence should cover specifically. In addition, Honeywell will provide the team with the instruction book for running tests on these components (called the "ditty books"). _4_._8 _C_o_v_e_r_t _C_h_a_n_n_e_l _A_n_a_l_y_s_i_s As part of the plans for MR11, a Covert Channel Analysis will be completed and documented by Honeywell. Channels that cannot be closed, will be audited, noised up, etc. _4_._9 _T_r_u_s_t_e_d _F_a_c_i_l_i_t_i_e_s _M_a_n_a_g_e_m_e_n_t Towards this effort, change_vol_registration will be removed from the admisitrator process. A limited service subsystem will be provided for use in the daemon process running hierarchy backup. This interface will restrict the set of commands available to the operator to only those required for backup functions. In addition, quits will be disabled for the daemon running this process. Furthermore, no daemons will sit at Multics command level. The documentation will state that operators should not be allowed to run hierarchy retrievers at a highly secure site. _4_._1_0 _D_e_s_i_g_n _S_p_e_c_i_f_i_c_a_t_i_o_n _a_n_d _V_e_r_i_f_i_c_a_t_i_o_n The MPM Reference Guide is both incomplete and inaccurate with respect to security. Not all of the rules are stated, and some of the things that are stated are misleading or wrong. It is necessary to state the security model that Multics implements, that being the Bell and LaPadula Model. Towards this effort, Chapter 6 of the MPM Reference Guide, Access Control, will be re-written to clearly describe the security policy implemented. An outline for this new chapter is being prepared for submission to the team. In addition, the interafaces to the TCB are being defined in several categories. There will be two sets: those for public release and privileged interfaces. Ultimately, the DTLS will include the subroutine manual description for each of the defined interfaces. For those interfaces which are gates, there will be three types: available for current use; available for current use by systems' Page 9. MTB-662 Multics Technical Bulletin B2 Security programmers; not recommended for current use. The documentation will accurately reflect to which category a gate belongs. _4_._1_1 _C_o_n_f_i_g_u_r_a_t_i_o_n _M_a_n_a_g_e_m_e_n_t In the past, changes to Multics were accomplished by proposing, reviewing, auditing, and installing the changes. A site armed with a previous set of source libraries and compiler could convince itself that it had indeed received the release it was supposed to, and nothing else. The deficiency is that the procedure is not written down. A configuration management strategy has been prepared and submitted to the team for approval. _4_._1_2 _S_e_c_u_r_i_t_y _F_e_a_t_u_r_e_s _U_s_e_r_s_' _G_u_i_d_e A chapter will be prepared that will contain a list of all the security related commands and a brief description of their functions and where to locate more detailed information. This chapter will become part of the MPM Reference Guide. _4_._1_3 _T_r_u_s_t_e_d _F_a_c_i_l_i_t_y _M_a_n_u_a_l A new System Administrators Users' Guide is being prepared. This information will be contained in that set of documents. An outline is currently being prepared.This is expected to be complete by MR11. _4_._1_4 _T_e_s_t _D_o_c_u_m_e_n_t_a_t_i_o_n There is currently no set of tests that can be run to verify the functional operation of Multics. The Criteria require that functional tests exist for the entire Trusted Computing Base. The Trusted Computing Base is that part of the system which implements security. For Multics, this is ring zero, ring one, and all privileged applications (i.e. the Answering Service). All of these are capable of subverting system security if they have a bug. Since both a functional test set and the resources to create one are lacking, the Evaluation Team has graciously volunteered to do most of the work. The team has implemented a good majority of the functional test suite. Honeywell will be responsible for completing the test suit in conjunction with the team and Page 10. Multics Technical Bulletin MTB-662 B2 Security integrating the tests into a coherent package. The following subsections further describe the tests. 4.14.1 TEST STRUCTURE The test set will consist of interface programs and scripts. There will be one interface program per software interface. Almost all of the software interfaces are gates to ring zero and ring one. The others are the software-callable interfaces to the various privileged applications. These interface programs are minimal commands that translate command language into arguments suitable for the gate. The scripts are sets of calls to the interfaces that exercise their functionality. When possible, they are exec_coms. However, some scripts of commands require the use of processes at different authorizations. For these, a benchmark driver system (already existing) will be used to drive software terminals. 4.14.2 TEST PROCEDURES Test procedures will consist of a series of runs of the scripts. By and large, the scripts will use compare_ascii technology to detect deviations from the correct behavior. However, some things (like log messages) are not really amenable to automatic verification, and will have to be verified by hand by the people running the test. Of course, the results of the first run of the tests will have to be manually verified. 4.14.3 TEST RESULTS The final results of the functional testing project are the documentation describing the tests, the procedures for running the tests, and a reference set of test output. The documentation of the tests and their procedures should be maintained in a reasonable format (possibly a PLM). 4.14.4 LONG-TERM IMPLICATIONS For functional testing to have any point, there has to be a management commitment to maintain and upgrade the tests as the system changes, and to require developers to run the tests when they change the system. This is part of the configuration management plan proposed. Page 11. MTB-662 Multics Technical Bulletin B2 Security _4_._1_5 _S_c_h_e_d_u_l_e The following is an overview description of the requirements to meet B2 with MR11. The effort required is in terms of man-weeks required. In two areas, Functional Testing and Design Documentation, some of the effort required has been accounted for in section A (*). For example, it is estimated that it will require 27 mw of effort to complete the functional testing. Of those 27 mw, 7 of them involve creating and running functional tests for some of the areas mentioned in section A. A more detailed schedule is available. Page 12. Multics Technical Bulletin MTB-662 B2 Security A. Remedy Functional Deficiencies Effort 1. Auditing 23 2. Communications Channel AIM 8 3. Directory Control 8 4. Operator Environment 16 5. Change new_proc -auth and logout -hold 1 6. IO Daemon Override Label 1 ---- 57 B. Fix Bugs Discovered by DODCSC and CISL during Functional Testing 1. Functional Testing 20 + 7* a. Completion of CISL portion of 12 Functional Tests b. Fix bugs found by CISL and DODCSC 8 2. Penetration Testing 12 a. Fix Security-related bugs ASAP 4 b. Respond to flaws found by Team 3 c. Resolve remaining bugs 5 3. Covert Channel Analysis 8 a. Perform CISL Covert Channel Analysis 4 b. Determine status of all identified channels 2 c. Resolution of channels 2 ---- 40 C. Security-Related Documentation 1. Descriptive Top-Level Specification (DTLS) 11 a. Reference Manual description of security policy and model 2 b. Trusted Computing Base (TCB) Interfaces 9 2. Security Features Information 4 3. Design Documentation - PLMs 28 + 8* a. All TCB Components 4. Trusted Facilities Manual 8 ---- 51 D. Change Control Procedures 1. Configuration Management Plan NA TOTAL = 148mw OR 36mm Page 13.