Multics Technical Bulletin MTB-649 B2 Security To: Distribution From: Benson I. Margulies Date: 02/17/84 Subject: A B2 Security Evaluation for Multics 1_ A_B_S_T_R_A_C_T_ After many years of apparent disinterest in computer security, the DoD has established a Computer Security Center. This Center has published a "Trusted Computer System Evaluation Criteria," and is in the process of evaluating several computer systems. The Criteria set out requirements for functionality, documentation, and configuration management for systems at various levels of security or trust. This MTB briefly describes the evaluation process, and goes on to discuss the results to date of the Multics evaluation, including system changes neccessary to reach the B2 level of the Criteria. Comments should be sent to the author: via Multics Mail: Margulies at either System-M, MIT, or CISL-SERVICE. via US Mail: Benson I. Margulies Honeywell Information Systems, inc. 4 Cambridge Center Cambridge, Massachusetts 02142 via telephone: (HVN) 261-9333, or (617) 492-9333 _________________________________________________________________ Multics project internal working documentation. Not to be reproduced or distributed outside the Multics project without the consent of the author or the author's management. Page 1. MTB-649 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 for modularization of implementation. The last, "A", requires that formal mathematical models be used to prove the correctness of the implementation. The "B" class is in turn split into three levels, B1, B2, B3. Readers interested in the specifics of 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 To evaluate a system, it is first neccessary to see where its documented behavior with respect to security conforms Criteria's levels. Then, it is neccessary to test whether the system functionally conforms to its documentation. Finally, it is neccessary to evaluate the system with respect to penetration resistance and covert channels. An area of particular concern is called "configuration management." This term is used to refer to the control of system changes, source and object libraries, and releases. The Criteria require that the vendor demonstrate adequate controls on these areas to insure that future releases of the system continue to meet the rated level. _________________________________________________________________ Order number CSC-STD-001-83, often referred to as the "Orange Book." Page 2. Multics Technical Bulletin MTB-649 B2 Security The DoD wishes to have accurate evaluations of as many vendor products as possible. The DoD also wishes to avoid the level of staffing that would be required to do complete evaluations of all vendor systems. Therefore, the Criteria set requirements for the vendor in the areas of design documentation and functional testing. Rather than having to test systems for themselves, the Center expects to be presented with a set of functional testing procedures run by the vendor as part of configuration management that prove that the system behaves as documented. The evaluation process is not yet complete. The Center has not yet decided how to manage recertification of new system releases. It is clear, though, that the requirements for functional testing, configuration management, and documentation have been chosen with an eye toward minimizing the effort required to recertify a system. 2_._3_ T__h_e S__c_h_e_d_u_l_e The schedule for 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. The later parts of the evaluation process (functional testing and penetration testing) may uncover other problems with the system. We expect that these problems will be appropriately classified as bugs. This list should be a complete list of deficiencies of the system as designed. This section is subsectioned in parallel with the Orange Book, for ease of reference. Each section begins with the Evaluation Team's reported deficience, and continuies with explanatory comments. Sections of the Orange Book where Multics meets 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_)_ RCPRM does not audit changes in the AIM classification of volumes and devices. In general, RCPRM does no useful auditing. See later sections for specification of the events that should be audited. Page 3. MTB-649 Multics Technical Bulletin B2 Security 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 IO Daemon allows users to over-ride the marking of each page with the AIM classification of the file printed, but does not audit this event. 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 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 like login. Second, the operators are not identified and authenticated at all. The check_acs feature does force a user name and password for dial and slave requests. However, it does not permit an access class to be specified, and 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. 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 disabled. A "Trusted Path" is a communication 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, causing the user to type information into files at an innappropriate classification. Page 4. Multics Technical Bulletin MTB-649 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 are incomplete. 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_)_ We have not provided the team with the results of a covert channel analysis. Not surprising, considering that we have not yet done one. 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 requires us to claim that Multics still intends to implement the Bell-LaPadua security model, which we do. Page 5. MTB-649 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 specifying those areas where the existing Multics documentation fails to meet the Criteria. 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. 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. Not surprising, considering that we have no 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 documentation. Readers are encouraged to look this section up in the Orange Book. Most of what is required is already present in partial or innaccurate form in the MPM. We have to make it complete, and then argue that it meets the requirement. 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 us to do a significant amount of work. Quite aside from whatever marketing requirement we may have to "make B2," most of the items are things that we ourselves would consider deficiencies. For example, it is certainly a failing of our current development strategies that we do not maintain a complete and coherent functional test suite for important system interfaces. Much of what is proposed here could be justified independently on "quality" grounds. Page 6. Multics Technical Bulletin MTB-649 B2 Security 4_._1_ F__u_n_c_t_i_o_n_a_l T__e_s_t_i_n_g 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 Computer Base. The Trusted Computer Base is that part of the system which implements security. For Multics, this is ring zero, ring one, the Answering Service, the IO Daemon, and the Backup Daemons. All of these are capable of subverting system security if they have a bug. For the purposes of the B2 evaluation, the important areas are rings zero and one and the Answering Service. Since we lack both a functional test set and the resources to create one, the Evaluation Team has graciously volunteered to do most of the work. They are implementing the test interfaces and exec_coms described below. We are responsable for integrating them into a coherent package. 4.1.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 Answering Service. 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.1.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. Page 7. MTB-649 Multics Technical Bulletin B2 Security 4.1.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 (preferably a PLM). 4.1.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. 4_._2_ D__o_c_u_m_e_n_t_a_t_i_o_n The MPM already tries to meet the documentation requirements of the Criteria. There are, however, a variety of deficiencies that must be corrected. Further, some of the documentation problems may turn out to really be code problems, where the documentation is correct, but the code is wrong. 4.2.1 SECURITY MODEL AND POLICY The MPM Reference Guide is both incomplete and innaccurate with respect to security. Not all of the rules are stated, and some of the things that are stated are misleading or flat wrong. However, it isn't all the book's fault. The code that implements the various rules as to what access is required to perform what operations is, as described below, poorly modularized. In some cases the system has been enforcing the wrong access restrictions for years. By rewriting this part of the documentation to be complete and clear, we will set out (for the first time) what we _i_n_t_e_n_d to implement in this area. Having that intention on paper, it will be a very small matter to change the programs that enforce the restrictions to enforce the right ones. It should be noted that these are not issues of gaping security holes. These are questions like "What ring should you have to be in to read the date-time contents modified of a mailbox?" 4.2.2 GATE/INTERFACE DOCUMENTATION The Criteria require that documentation be available to all interfaces to the TCB, documented for customers or not. It seems Page 8. Multics Technical Bulletin MTB-649 B2 Security superfluous to point out that a lot of work is wasted in the project in re-learning how to use gates that are not in the published documentation because they are "internal," and not in any internal documentation because we haven't time to maintain or create it. All ring zero and one gates will be documented with MPM style documentation as part of this project. There are several choices for this documentation. We could create an "Internal Interface PLM." Alternatively, we could document them with the rest of the subroutines, and mark each page clearly "Internal interface, subject to change." The important point is that keeping this documentation up to date must have equal priority with the supported interfaces. 4_._3_ C__o_n_f_i_g_u_r_a_t_i_o_n M__a_n_a_g_e_m_e_n_t Multics already has a perfectly adequate configurement management system. The process of proposing, reviewing, auditing, and installing changes meets the Criteria. A site armed with a previous set of source libraries and compiler can convince itself that it has indeed received the release it was supposed to, and nothing else. Our deficiency is that we do not have the procedure written down to show the Team. It is neccessary that the MAB's be updated or written as needed, and made available to the team. 4_._4_ S__y_s_t_e_m C__h_a_n_g_e_s (__i_n O__v_e_r_v_i_e_w)_ This section outlines the changes required to the system to cover the deficiencies listed above. 4.4.1 AUDITING -- NEW LOGGING FACILITIES The Criteria require us to audit many more events than we audit today. Out existing mechanisms for auditing (the syserr log and the Answering Service log) cannot handle the additional load and provide reasonable performance. We need to design and implement a better logging facility. In the long run, the new mechanism should superceed the existing mechanisms so that all messages are handled consistently. In the short run, however, we can replace only the syserr log with the new mechanism and leave the Answering Service log alone. A future MTB will discuss these issues in more detail. Page 9. MTB-649 Multics Technical Bulletin B2 Security 4.4.2 AUDITING -- NEW THINGS TO AUDIT This section describes some of the more important areas where new auditing is to be added. In general, a pass over the system adding audit trails where appropriate will have to be made. These are the areas where significant work will have to be done to be able to add the audit trails. 4.4.2.1 Successful accesses The hardcore only audits access violations. The Criteria require us to audit successful accesses. This implies audit of each make-known, and of any activation that changes the access available in the SDW. It also requires audit of all directory control operations, such as appends, deletes, and acl changes. 4.4.2.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 is 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 _w_h_y the access was denied, only that the user lacked sufficient effective access. This requires us to do more than just add audit messages to modules. We have to change the interface to the program that evaluates effective access so that enough information is available to generate the audit trail. 4.4.2.3 Administration There is no auditing of security-related administration. For PDT and SAT AIM fields, we do have the audit trail of the table installation. It does not tell us what was done, but at least it identifies the doer. For the PNT we lack even that. The PNT will have to be moved to an inner ring so that changes to it can be audited. Page 10. Multics Technical Bulletin MTB-649 B2 Security 4.4.3 COMMUNICATIONS CHANNEL AIM This is by far the most difficult area to understand, though the actual code changes are not all that bad. The Criteria are not very specific, but the gaps have been filled by guidance from the Team. The first part of this section is an expanded description of the requirements in this area as we have elucidated them with the team's help. Some of these are requirements for features of the system, and some of them are restrictions on how site administrators should use them. The second part of this section describes the changes to the system needed to meet the requirements. 4.4.3.1 The Requirement for Communications Channel AIM 4.4.3.1.1 Channels must have AIM ranges The Criteria require that each channel have an associated AIM range. This specifies the maximum and minimum classification of information that may pass over the channel. The crucial concept here is that this range describes not the channel itself, but rather the entity(ies) at the other end. Thus, communications channels are treated like devices. A single level communications channel is connected to some entity at a particular authorization. A multi-level communications channel is connectable to one or more entities each of which has a single level which is within the range. One might also imagine a communications connection to a multi-class entity, which would accept marked data of different classes. As we will see in the next section, this configuration is not yet defined in the Criteria. 4.4.3.1.2 Channels are attached at a single level The Criteria do not yet deal with communications networks. They do not yet recognize protocols that allow data transmitted over a network to be marked. Some day, the Center expects to release a set of Criteria for communications devices and networks that includes trusted protocols. But for this evaluation, any attachment of a communications channel is a single level device at a single authorization. This is precisely the way that RCPRM handles multi-class devices like tape drives. The drive has a range of classifications, but any given attachment is at a single level. Page 11. MTB-649 Multics Technical Bulletin B2 Security 4.4.3.1.3 Multi-class channels are usually inappropriate While the Criteria allow us to define multi-class channels, we have to be very clear about when it is appropriate to use them, both for our customers and ourselves. When a process attaches a multi-class tape drive at a single level, the information is actually being transmitted to a single-class tape volume. Under the Criteria, there could be multi-class volumes, but there would have to be trusted software to write and read them. Multics does not have any such trusted software. RCPRM allows the registration of multi-class volumes, but no site should ever do so unless they had written a ring one trusted interface to read and write them. With communications channels, the system usually has no knowledge of what is on the other end. If the system has no way of negotiating the access classification of the other end of the channel, then it is incorrect for the channel to be given an access classification range. Administrative documentation will have to warn sites of this. 4.4.3.1.4 Identification and Authentication Whenever a user is connected to the system, the system must solicit a user id, password, and access class. In particular, dial and slave pre-access commands must identify and authenticate the "user" who gives the command. This requirement obviously turns a blind eye to computer-computer links. When the Criteria are extended to include network issues, they will address more appropriate ways for system to authenticate and identify each other. 4.4.3.2 Code changes to meet the Criteria These sections describe the changes to the existing code needed to meet the requirement above. Some of the changes described below have already been made as part of the TCP-IP RPQ. Very few people are familiar with these changes. For clarity, then, the following sections describe the entire design. They describe how the system should work, with no reference to how it works now. 4.4.3.2.1 Identification and Authentication By site option, the slave and dial pre-access commands will require the use of the -user control argument. The Answering Service will prompt for the password of the user name given. The -access_class control argument will be optional. The user's PNT and PDT access class restrictions will apply to the access class Page 12. Multics Technical Bulletin MTB-649 B2 Security given with -access_class. For example: dial internet -user Margulies.Multics -acc system_high 4.4.3.2.2 Extensions to Required Access Class If a non-privileged process attaches (for dial_out or priv_attach) a channel, it is implicitly requesting connection to some entity at the process' current authorization. A privileged processes can specify an access class other than its current authorization, subject to the rules for the communications privilege which is described below. The Answering Service honors this request as follows: if the channel is single-class, it must be the requested class. If the channel is multi-class, and a user has been identified and authenticated via a slave or dial pre-access command, then that single class specified by the user on the slave or dial pre-access command line must be the requested class. If the channel is not associated with a user via a pre-access command, then the mechanism described below is used to determine the single access class. Note that the attachment of a channel that has connected via the accept_dials mechanism is equivalent to a priv_attach for the purposes of access class checking. If the channel is not single-class, and this is a request to priv_attach a channel, the Answering Service makes a control order call to the channel called "get_required_access_class". If the underlying mechanism has some knowledge (due to protocol) or the access class of the entity on the other end of the channel, it will return it. This access class becomes the single level for the purposes of the attachment. If the underlying mechanism has no such knowledge, then an error code of error_table_$undefined_order_request will be returned. If a user was authenticated and identified this error is benign, and the access class determined from identification and authentication becomes the single access class of the attachment. If any other error code is returned, or if no identification and authentication has taken place (e.g., the channel is in slave service), then the Answering Service will not honor the request. It is not valid to attach a multi-class channel unless the access class of the attachment can be determined. If, on the other hand, this is a request to dial out a channel, the Answering service makes a control order call to the channel of "set_required_access_class." If this control order succeeds, it means that the underlying communications mechanism undertakes to guarantee that the other end of the channel is at that specified access class, and the requested access class becomes the single level for the attachment. This control order Page 13. MTB-649 Multics Technical Bulletin B2 Security must succeed for a dial_out of a multi-class channel. If any error is returned, the request is not honored. The only standard multiplexer that supports these control orders is the sty (software terminal) multiplexer. A set_required_access_class control order made on one end of a sty sets the access class of the other end. A process dialing out a sty specifies the access class of the connection, and the process on the other end sees the channel at that class. 4.4.3.2.3 The comm privilege As specified so far, all of this mechanism only allow entities of identical access classes to communicate. To support the construction of trusted applications, a communications (comm) privilege is defined. A process with the comm privilege may attach a communications channel at an accesss class less than or equal to its authorization. Thus, a process dialing out with the comm privilege may request that the access class of a channel be set to any single level less than or equal to the process' current authorization. A process making a privileged attachment or accepting dials with the comm privilege may attach any channel whose access class, as determined by pre-access command, protocol, or single-class definition, is less than or equal to the process' current authorization. A process making a privileged dial_out must specify the desired access class, and it must be less than or equal to the process' authorization. As described above, the channel must either be single-class at the specified class, or multi-class and support set_required_access_class. 4.4.3.2.4 Summary of access control checks These diagrams describe the access check for multi-class channels. In the single-class case, the channel max and min are the same, and everything between them must be equal to them. For a priv_attach with a non-privileged process: -----------------------channel max------------------------------- unprivileged { user auth from pre-access process EQUAL to both { authorization { { protocol auth from control order -----------------------channel min------------------------------- Page 14. Multics Technical Bulletin MTB-649 B2 Security For a priv_attach with a privileged process: --------------------process auth--------------------------------- ---channel max--- user auth from pre-access EQUAL to protocol auth from control order ---channel min--- --------------------system_low----------------------------------- For a dial_out: --------------------process auth--------------------------------- ---channel max--- specified auth for priv. process OR process' auth for nonpriv. process ---channel min--- --------------------system_low---------------------------------- 4.4.4 FILE SYSTEM The changes to the file system proper are small but important. As described above, there are currently open questions about the access decisions made and error codes returned by some of the file system interfaces. Once we clear up the documentation, we can make the minor code changes to make the behavior of the code conform to the documentation. An area of particular concern is obsolete interfaces. The retention of obsolete interfaces adds to the burden of functional testing. Where possible, these should be removed. If they cannot be removed, they should be removed from the supervisor. There are two approaches to this. Where we have two different hardcore programs that implement the same thing (e.g. acl.pl1 and asd_.pl1 for acls), we can replace the old program with a Page 15. MTB-649 Multics Technical Bulletin B2 Security stub that calls the new program. It is arguable that if the stub calls the same entrypoints as the gates to the new interfaces that seperate testing of the old gate interfaces will not be required. Designing a way to redirect calls to certain entries of a gate to a user ring stub would be even better. This could be done with a linkage error handler and a feature of the gate actor that returned the name of the replacement program. 4.4.5 BETTER CONTROL OF PRIVILEGES Currently, access to privileges is an all-or-nothing affair. It should be possible, for example, to give a process access to the comm privilege withoput giving it seg or dir. This can be arranged by making system_privilege_ a gate to ring one that checks acs's. By putting the acs's into >sl1 (and therefore on the system tape), and links in >sc1>rcp, this mechanism can be guaranteed to work in the face of file system damage. 4.4.6 THE ALL-POWERFUL OPERATOR Future MTB's will describe limited command subsystems for the Hierarchy and Volume Backup daemons, and for an authentication mechanism for operators. 4_._5_ C__o_v_e_r_t C__h_a_n_n_e_l_s The Criteria require us to make and document a covert channel analysis for covert storage channels. A memo has already been circulated describing the process of making this analysis. It will be published as an MTB. 5_ F_U_T_U_R_E_ D_I_R_E_C_T_I_O_N_S_ This section presents some thoughts on where we go after we make B2. At this time, they represent the author's personal opinion, and should not be held against anyone else. 5_._1_ A__t_t_i_t_u_d_e There are some general principles of design and implementation. We should try to apply them consistently to the entire system. Page 16. Multics Technical Bulletin MTB-649 B2 Security 5.1.1 TESTING IS IMPORTANT For one last time in this MTB, I will point out that our current lack of testing technology is little short of criminal. It contributes to our tendency to ship buggy code. It makes it difficuly to detect inadvertent functional regressions. Worse yet, people often think that they cannot afford to spend the time to build real, permanent, testing technology. At best, they arrange an ad-hoc test methodology and let it go, leaving the next maintainer to repeat the exercise. At worse, they just depend on exposure to find the problems. 5.1.2 DESIGN FOR ASSURANCE It is possible to design software to be testable. It is possible to introduce special code paths that exercise features that are normally exercised only under extraordinary circumstances. It is possible to put in test features that take faults in uncomforable places. All of this could be part of our coding standards. 5.1.3 SECURITY-RELATED MODULARIZATION --> IMPROVED QUALITY The B2 criteria call for code modularization of the TCB to make it possible for evaluation team to really convince themselves that things work without reading every line of every program. The B3 criteria make more demands in this area. This kind of modularization produces a higher quality product for our users. It makes it quite unlikely that the code will suffer from defects involving incorrect access control decisions, because all such decisions would be made in a central place. 5_._2_ S__e_c_u_r_i_t_y C__o_n_c_e_r_n_s Focusing on the area of security functionality, there are two areas we can persue in the future. 5.2.1 MEETING THE SPIRIT OF B2 Due to lack of time, the evaluation process is not paying much attention to several trusted ring one applications, particularly the dumpers. It is important that these applications be brought up to the same functional standards as the rest of the system. For example, we should be able to demonstrate that the Hierarchy Dumper / Retriever will always reload information at the access class it had when it was dumped. Page 17. MTB-649 Multics Technical Bulletin B2 Security 5.2.2 MAKING B3 Multics is not far from B3. We already have features required for B3 and not required for B2. It is not unreasonable to set a goal of making a B3 rating in the next few years. B3 is the highest rating that can be achieved without the use of formal mathematical methods that are just barely practical at this time, and which can probably never be applied after the fact. 5.2.2.1 This is NOT Guardian I want to make it quite clear that the GUARDIAN proposal, which called for the removal of all pathname management from ring zero, is not required to make B3, and is not proposed here. 5.2.2.2 Centralize Access Control Decisions The single largest barrier to a B3 rating for Multics is the ad-hoc manner in which access control decisions are made in the file system. The B3 criteria would require us to make a single module which answered "yes" or "no" to any request for access to an object, and supplied the correct error code to return to the user in case of a "no." This module would be responsable for all audit trails. Page 18.