The following paper was written by Tom Oke of ACTC to describe the issues related to making the proposed Unix subsystem for Multics into a B2 system. This paper is valuable as a tutorial to help one understand the issues related to security ratings. It contains: - A summary of the 6 generic requirements (from the Orange book) - A summary of the differences between the different ratings as related to each of the requirements (from the Orange book) - A summary description of Unix System V Rel 2 and a guess at how it would be rated. (useful to help relate these security issues to a real system) - A brief description of the Unix implementation proposed for Multics and how it would be modified to achieve a B2 rating. (useful to help explain what it means to add something to a B2 system and get it rated) Multics Technical Bulletin MTB-Draft 1 UNIX-M Security To: Distribution From: T. Oke Date: 08/16/85 Subject: UNIX-M Security Aspects Comments should be sent to the author: via Multics Mail: Oke on System M. via Mail: Tom Oke Advanced Computing Technology Centre Room #301, 1620, 29th Street NW Calgary, Alberta, Canada T2N 4L7 (403) 270-5414 _________________________________________________________________ Multics project internal working documentation. Not to be reproduced or distributed outside the Multics project. Page i Multics Technical Bulletin MTB-Draft 1 UNIX-M Security _1 _A_B_S_T_R_A_C_T This MTB deals with the aspects of security for UNIX-M, and security problems created within Multics by UNIX-M. It deals extensively with the DoDCSC Trusted Computer System Evaluation Criteria. _2 _T_H_E _C_R_I_T_E_R_I_A The following sections are taken from the DoDCSC Security Critia. Fundamental Computer Security Requirements Any discussion of computer security necessarily starts from a statement of requirements, i.e., what it really means to call a computer system "secure." In general, secure systems will control, through use of specific security features, access to information such that only properly authorized individuals, or processes operating on their behalf, will have access to read, write, create, or delete information. Six fundamental requirements are derived from this basic statement of objective: four deal with what needs to be provided to control access to information; and two deal with how one can obtain credible assurances that this is accomplished in a trusted computer system. POLICY Requirement 1 - SECURITY POLICY - There must be an explicit and well-defined security policy enforced by the system. Given identified subjects and objects, there must be a set of rules that are used by the system to determine whether a given subject can be permitted to gain access to a specific object. Computer systems of interest must enforce a mandatory security policy that can effectively implement access rules for handling sensitive (e.g., classified) information.[7] These rules include requirements such as: No person lacking proper personnel security clearance shall obtain access to classified information. In addition, discretionary security controls are required to ensure that only selected users or groups of users may obtain access to data (e.g., based on a need-to-know). Requirement 2 - MARKING - Access control labels must be associated with objects. In order to control access to Page 1 MTB-Draft 1 Multics Technical Bulletin UNIX-M Security information stored in a computer, according to the rules of a mandatory security policy, it must be possible to mark every object with a label that reliably identifies the object's sensitivity level (e.g., classification), and/or the modes of access accorded those subjects who may potentially access the object. ACCOUNTABILITY Requirement 3 - IDENTIFICATION - Individual subjects must be identified. Each access to information must be mediated based on who is accessing the information and what classes of information they are authorized to deal with. This identification and authorization information must be securely maintained by the computer system and be associated with every active element that performs some security-relevant action in the system. Requirement 4 - ACCOUNTABILITY - Audit information must be selectively kept and protected so that actions affecting security can be traced to the responsible party. A trusted system must be able to record the occurrences of security-relevant events in an audit log. The capability to select the audit events to be recorded is necessary to minimize the expense of auditing and to allow efficient analysis. Audit data must be protected from modification and unauthorized destruction to permit detection and after-the-fact investigations of security violations. ASSURANCE Requirement 5 - ASSURANCE - The computer system must contain hardware/software mechanisms that can be independently evaluated to provide sufficient assurance that the system enforces requirements 1 through 4 above. In order to assure that the four requirements of Security Policy, Marking, Identification, and Accountability are enforced by a computer system, there must be some identified and unified collection of hardware and software controls that perform those functions. These mechanisms are typically embedded in the operating system and are designed to carry out the assigned tasks in a secure manner. The basis for trusting such system mechanisms in their operational setting must be clearly documented such that it is possible to independently examine the evidence to evaluate their sufficiency. Requirement 6 - CONTINUOUS PROTECTION - The trusted mechanisms that enforce these basic requirements must be continuously protected against tampering and/or Page 2 Multics Technical Bulletin MTB-Draft 1 UNIX-M Security unauthorized changes. No computer system can be considered truly secure if the basic hardware and software mechanisms that enforce the security policy are themselves subject to unauthorized modification or subversion. The continuous protection requirement has direct implications throughout the computer system's life-cycle. These fundamental requirements form the basis for the individual evaluation criteria applicable for each evaluation division and class. The interested reader is referred to Section 5 of this document, "Control Objectives for Trusted Computer Systems," for a more complete discussion and further amplification of these fundamental requirements as they apply to general-purpose information processing systems and to Section 7 for amplification of the relationship between Policy and these requirements. _3 _D_O_D_C_S_C _R_E_Q_U_I_R_E_M_E_N_T _D_I_R_E_C_T_O_R_Y The following section lists an extract from the DoDCSC security criteria, indicating the requirements, listed in sections of requirements, with sub-sets of requirement changes per category classification. Page 3 MTB-Draft 1 Multics Technical Bulletin UNIX-M Security Requirement Directory This appendix lists requirements defined in "Department of Defense Trusted Computer System Evaluation Criteria" alphabetically rather than by class. It is provided to assist in following the evolution of a requirement through the classes. For each requirement, three types of criteria may be present. Each will be preceded by the word: NEW, CHANGE, or ADD to indicate the following: NEW: Any criteria appearing in a lower class are superseded by the criteria that follow. CHANGE: The criteria that follow have appeared in a lower class but are changed for this class. Highlighting is used to indicate the specific changes to previously stated criteria. ADD: The criteria that follow have not been required for any lower class, and are added in this class to the previously stated criteria for this requirement. Abbreviations are used as follows: NR: (No Requirement) This requirement is not included in this class. NAR: (No Additional Requirements) This requirement does not change from the previous class. The reader is referred to Part I of this document when placing new criteria for a requirement into the complete context for that class. Figure 1 provides a pictorial summary of the evolution of requirements through the classes. Page 4 Multics Technical Bulletin MTB-Draft 1 UNIX-M Security Audit C1: NR. C2: NEW: The TCB shall be able to create, maintain, and protect from modification or unauthorized access or destruction an audit trail of accesses to the objects it protects. The audit data shall be protected by the TCB so that read access to it is limited to those who are authorized for audit data. The TCB shall be able to record the following types of events: use of identification and authentication mechanisms, introduction of objects into a user's address space (e.g., file open, program initiation), deletion of objects, and actions taken by computer operators and system administrators and/or system security officers. For each recorded event, the audit record shall identify: date and time of the event, user, type of event, and success or failure of the event. For identification/authentication events the origin of request (e.g., terminal ID) shall be included in the audit record. For events that introduce an object into a user's address space and for object deletion events the audit record shall include the name of the object. The ADP system administrator shall be able to selectively audit the actions of any one or more users based on individual identity. B1: CHANGE: For events that introduce an object into a user's address space and for object deletion events the audit record shall include the name of the object and the object's security level. The ADP system administrator shall be able to selectively audit the actions of any one or more users based on individual identity and/or object security level. ADD: The TCB shall also be able to audit any override of human-readable output markings. B2: ADD: The TCB shall be able to audit the identified events that may be used in the exploitation of covert storage channels. B3: ADD: The TCB shall contain a mechanism that is able to monitor the occurrence or accumulation of security auditable events that may indicate an imminent violation of security policy. This mechanism shall be able to immediately notify the security administrator when thresholds are exceeded. Page 5 MTB-Draft 1 Multics Technical Bulletin UNIX-M Security A1: NAR. Page 6 Multics Technical Bulletin MTB-Draft 1 UNIX-M Security Configuration Management C1: NR. C2: NR. B1: NR. B2: NEW: During development and maintenance of the TCB, a configuration management system shall be in place that maintains control of changes to the descriptive top-level specification, other design data, implementation documentation, source code, the running version of the object code, and test fixtures and documentation. The configuration management system shall assure a consistent mapping among all documentation and code associated with the current version of the TCB. Tools shall be provided for generation of a new version of the TCB from source code. Also available shall be tools for comparing a newly generated version with the previous TCB version in order to ascertain that only the intended changes have been made in the code that will actually be used as the new version of the TCB. B3: NAR. A1: CHANGE: During the entire life-cycle, i.e., during the design, development, and maintenance of the TCB, a configuration management system shall be in place for all security-relevant hardware, firmware, and software that maintains control of changes to the formal model, the descriptive and formal top-level specifications, other design data, implementation documentation, source code, the running version of the object code, and test fixtures and documentation. Also available shall be tools, maintained under strict configuration control, for comparing a newly generated version with the previous TCB version in order to ascertain that only the intended changes have been made in the code that will actually be used as the new version of the TCB. ADD: A combination of technical, physical, and procedural safeguards shall be used to protect from unauthorized Page 7 MTB-Draft 1 Multics Technical Bulletin UNIX-M Security modification or destruction the master copy or copies of all material used to generate the TCB. Covert Channel Analysis C1: NR. C2: NR. B1: NR. B2: NEW: The system developer shall conduct a thorough search for covert storage channels and make a determination (either by actual measurement or by engineering estimation) of the maximum bandwidth of each identified channel. (See the Covert Channels Guideline section.) B3: CHANGE: The system developer shall conduct a thorough search for covert channels and make a determination (either by actual measurement or by engineering estimation) of the maximum bandwidth of each identified channel. A1: ADD: Formal methods shall be used in the analysis. Page 8 Multics Technical Bulletin MTB-Draft 1 UNIX-M Security Design Documentation C1: NEW: Documentation shall be available that provides a description of the manufacturer's philosophy of protection and an explanation of how this philosophy is translated into the TCB. If the TCB is composed of distinct modules, the interfaces between these modules shall be described. C2: NAR. B1: ADD: An informal or formal description of the security policy model enforced by the TCB shall be available and an explanation provided to show that it is sufficient to enforce the security policy. The specific TCB protection mechanisms shall be identified and an explanation given to show that they satisfy the model. B2: CHANGE: The interfaces between the TCB modules shall be described. A formal description of the security policy model enforced by the TCB shall be available and proven that it is sufficient to enforce the security policy. ADD: The descriptive top-level specification (DTLS) shall be shown to be an accurate description of the TCB interface. Documentation shall describe how the TCB implements the reference monitor concept and give an explanation why it is tamperproof, cannot be bypassed, and is correctly implemented. Documentation shall describe how the TCB is structured to facilitate testing and to enforce least privilege. This documentation shall also present the results of the covert channel analysis and the tradeoffs involved in restricting the channels. All auditable events that may be used in the exploitation of known covert storage channels shall be identified. The bandwidths of known covert storage channels, the use of which is not detectable by the auditing mechanisms, shall be provided. (See the Covert Channel Guideline section.) B3: ADD: The TCB implementation (i.e., in hardware, firmware, and software) shall be informally shown to be consistent with the DTLS. The elements of the DTLS shall be shown, using informal techniques, to correspond to the elements of the TCB. Page 9 MTB-Draft 1 Multics Technical Bulletin UNIX-M Security A1: CHANGE: The TCB implementation (i.e., in hardware, firmware, and software) shall be informally shown to be consistent with the formal top-level specification (FTLS). The elements of the FTLS shall be shown, using informal techniques, to correspond to the elements of the TCB. ADD: Hardware, firmware, and software mechanisms not dealt with in the FTLS but strictly internal to the TCB (e.g., mapping registers, direct memory access I/O) shall be clearly described. Design Specification and Verification C1: NR. C2: NR. B1: NEW: An informal or formal model of the security policy supported by the TCB shall be maintained that is shown to be consistent with its axioms. B2: CHANGE: A formal model of the security policy supported by the TCB shall be maintained that is proven consistent with its axioms. ADD: A descriptive top-level specification (DTLS) of the TCB shall be maintained that completely and accurately describes the TCB in terms of exceptions, error messages, and effects. It shall be shown to be an accurate description of the TCB interface. B3: ADD: A convincing argument shall be given that the DTLS is consistent with the model. A1: CHANGE: The FTLS shall be shown to be an accurate description of the TCB interface. A convincing argument shall be given that the DTLS is consistent with the model and a combination of formal and informal techniques shall be used to show that the FTLS is consistent with the model. Page 10 Multics Technical Bulletin MTB-Draft 1 UNIX-M Security ADD: A formal top-level specification (FTLS) of the TCB shall be maintained that accurately describes the TCB in terms of exceptions, error messages, and effects. The DTLS and FTLS shall include those components of the TCB that are implemented as hardware and/or firmware if their properties are visible at the TCB interface. This verification evidence shall be consistent with that provided within the state-of-the-art of the particular Computer Security Center- endorsed formal specification and verification system used. Manual or other mapping of the FTLS to the TCB source code shall be performed to provide evidence of correct implementation. Device Labels C1: NR. C2: NR. B1: NR. B2: NEW: The TCB shall support the assignment of minimum and maximum security levels to all attached physical devices. These security levels shall be used by the TCB to enforce constraints imposed by the physical environments in which the devices are located. B3: NAR. A1: NAR. Discretionary Access Control C1: NEW: The TCB shall define and control access between named users and named objects (e.g., files and programs) in the ADP system. The enforcement mechanism (e.g., self/group/public controls, access control lists) shall allow users to specify and control sharing of those objects by named individuals or defined groups or both. Page 11 MTB-Draft 1 Multics Technical Bulletin UNIX-M Security C2: CHANGE: The enforcement mechanism (e.g., self/group/public controls, access control lists) shall allow users to specify and control sharing of those objects by named individuals, or defined groups of individuals, or by both. ADD: The discretionary access control mechanism shall, either by explicit user action or by default, provide that objects are protected from unauthorized access. These access controls shall be capable of including or excluding access to the granularity of a single user. Access permission to an object by users not already possessing access permission shall only be assigned by authorized users. B1: NAR. B2: NAR. B3: CHANGE: The enforcement mechanism (e.g., access control lists) shall allow users to specify and control sharing of those objects. These access controls shall be capable of specifying, for each named object, a list of named individuals and a list of groups of named individuals with their respective modes of access to that object. ADD: Furthermore, for each such named object, it shall be possible to specify a list of named individuals and a list of groups of named individuals for which no access to the object is to be given. A1: NAR. Page 12 Multics Technical Bulletin MTB-Draft 1 UNIX-M Security Exportation of Labeled Information C1: NR. C2: NR. B1: NEW: The TCB shall designate each communication channel and I/O device as either single-level or multilevel. Any change in this designation shall be done manually and shall be auditable by the TCB. The TCB shall maintain and be able to audit any change in the current security level associated with a single-level communication channel or I/O device. B2: NAR. B3: NAR. A1: NAR. Exportation to Multilevel Devices C1: NR. C2: NR. B1: NEW: When the TCB exports an object to a multilevel I/O device, the sensitivity label associated with that object shall also be exported and shall reside on the same physical medium as the exported information and shall be in the same form (i.e., machine-readable or human-readable form). When the TCB exports or imports an object over a multilevel communication channel, the protocol used on that channel shall provide for the unambiguous pairing between the sensitivity labels and the associated information that is sent or received. B2: NAR. Page 13 MTB-Draft 1 Multics Technical Bulletin UNIX-M Security B3: NAR. A1: NAR. Exportation to Single-Level Devices C1: NR. C2: NR. B1: NEW: Single-level I/O devices and single-level communication channels are not required to maintain the sensitivity labels of the information they process. However, the TCB shall include a mechanism by which the TCB and an authorized user reliably communicate to designate the single security level of information imported or exported via single-level communication channels or I/O devices. B2: NAR. B3: NAR. A1: NAR. Identification and Authentication C1: NEW: The TCB shall require users to identify themselves to it before beginning to perform any other actions that the TCB is expected to mediate. Furthermore, the TCB shall use a protected mechanism (e.g., passwords) to authenticate the user's identity. The TCB shall protect authentication data so that it cannot be accessed by any unauthorized user. C2: ADD: The TCB shall be able to enforce individual accountability by providing the capability to uniquely identify each individual ADP system user. The TCB shall also provide the capability of associating this identity with all auditable actions taken by that individual. Page 14 Multics Technical Bulletin MTB-Draft 1 UNIX-M Security B1: CHANGE: Furthermore, the TCB shall maintain authentication data that includes information for verifying the identity of individual users (e.g., passwords) as well as information for determining the clearance and authorizations of individual users. This data shall be used by the TCB to authenticate the user's identity and to determine the security level and authorizations of subjects that may be created to act on behalf of the individual user. B2: NAR. B3: NAR. A1: NAR. Label Integrity C1: NR. C2: NR. B1: NEW: Sensitivity labels shall accurately represent security levels of the specific subjects or objects with which they are associated. When exported by the TCB, sensitivity labels shall accurately and unambiguously represent the internal labels and shall be associated with the information being exported. B2: NAR. B3: NAR. A1: NAR. Labeling Human-Readable Output C1: NR. Page 15 MTB-Draft 1 Multics Technical Bulletin UNIX-M Security C2: NR. B1: NEW: The ADP system administrator shall be able to specify the printable label names associated with exported sensitivity labels. The TCB shall mark the beginning and end of all human-readable, paged, hardcopy output (e.g., line printer output) with human- readable sensitivity labels that properly* represent the sensitivity of the output. The TCB shall, by default, mark the top and bottom of each page of human-readable, paged, hardcopy output (e.g., line printer output) with human-readable sensitivity labels that properly* represent the overall sensitivity of the output or that properly* represent the sensitivity of the information on the page. The TCB shall, by default and in an appropriate manner, mark other forms of human-readable output (e.g., maps, graphics) with human- readable sensitivity labels that properly* represent the sensitivity of the output. Any override of these marking defaults shall be auditable by the TCB. B2: NAR. B3: NAR. A1: NAR. ____________________________________________________________ * The hierarchical classification component in human-readable sensitivity labels shall be equal to the greatest hierarchical classification of any of the information in the output that the labels refer to; the non-hierarchical category component shall include all of the non-hierarchical categories of the information in the output the labels refer to, but no other non-hierarchical categories. ____________________________________________________________ Labels C1: NR. C2: NR. Page 16 Multics Technical Bulletin MTB-Draft 1 UNIX-M Security B1: NEW: Sensitivity labels associated with each subject and storage object under its control (e.g., process, file, segment, device) shall be maintained by the TCB. These labels shall be used as the basis for mandatory access control decisions. In order to import non- labeled data, the TCB shall request and receive from an authorized user the security level of the data, and all such actions shall be auditable by the TCB. B2: CHANGE: Sensitivity labels associated with each ADP system resource (e.g., subject, storage object) that is directly or indirectly accessible by subjects external to the TCB shall be maintained by the TCB. B3: NAR. A1: NAR. Page 17 MTB-Draft 1 Multics Technical Bulletin UNIX-M Security Mandatory Access Control C1: NR. C2: NR. B1: NEW: The TCB shall enforce a mandatory access control policy over all subjects and storage objects under its control (e.g., processes, files, segments, devices). These subjects and objects shall be assigned sensitivity labels that are a combination of hierarchical classification levels and non-hierarchical categories, and the labels shall be used as the basis for mandatory access control decisions. The TCB shall be able to support two or more such security levels. (See the Mandatory Access Control guidelines.) The following requirements shall hold for all accesses between subjects and objects controlled by the TCB: A subject can read an object only if the hierarchical classification in the subject's security level is greater than or equal to the hierarchical classification in the object's security level and the non-hierarchical categories in the subject's security level include all the non-hierarchical categories in the object's security level. A subject can write an object only if the hierarchical classification in the subject's security level is less than or equal to the hierarchical classification in the object's security level and all the non-hierarchical categories in the subject's security level are included in the non-hierarchical categories in the object's security level. B2: CHANGE: The TCB shall enforce a mandatory access control policy over all resources (i.e., subjects, storage objects, and I/O devices) that are directly or indirectly accessible by subjects external to the TCB. The following requirements shall hold for all accesses between all subjects external to the TCB and all objects directly or indirectly accessible by these subjects: B3: NAR. A1: NAR. Page 18 Multics Technical Bulletin MTB-Draft 1 UNIX-M Security Object Reuse C1: NR. C2: NEW: When a storage object is initially assigned, allocated, or reallocated to a subject from the TCB's pool of unused storage objects, the TCB shall assure that the object contains no data for which the subject is not authorized. B1: NAR. B2: NAR. B3: NAR. A1: NAR. Security Features User's Guide C1: NEW: A single summary, chapter, or manual in user documentation shall describe the protection mechanisms provided by the TCB, guidelines on their use, and how they interact with one another. C2: NAR. B1: NAR. B2: NAR. B3: NAR. A1: NAR. Security Testing Page 19 MTB-Draft 1 Multics Technical Bulletin UNIX-M Security C1: NEW: The security mechanisms of the ADP system shall be tested and found to work as claimed in the system documentation. Testing shall be done to assure that there are no obvious ways for an unauthorized user to bypass or otherwise defeat the security protection mechanisms of the TCB. (See the Security Testing guidelines.) C2: ADD: Testing shall also include a search for obvious flaws that would allow violation of resource isolation, or that would permit unauthorized access to the audit or authentication data. B1: NEW: The security mechanisms of the ADP system shall be tested and found to work as claimed in the system documentation. A team of individuals who thoroughly understand the specific implementation of the TCB shall subject its design documentation, source code, and object code to thorough analysis and testing. Their objectives shall be: to uncover all design and implementation flaws that would permit a subject external to the TCB to read, change, or delete data normally denied under the mandatory or discretionary security policy enforced by the TCB; as well as to assure that no subject (without authorization to do so) is able to cause the TCB to enter a state such that it is unable to respond to communications initiated by other users. All discovered flaws shall be removed or neutralized and the TCB retested to demonstrate that they have been eliminated and that new flaws have not been introduced. (See the Security Testing Guidelines.) B2: CHANGE: All discovered flaws shall be corrected and the TCB retested to demonstrate that they have been eliminated and that new flaws have not been introduced. ADD: The TCB shall be found relatively resistant to penetration. Testing shall demonstrate that the TCB implementation is consistent with the descriptive top-level specification. B3: CHANGE: The TCB shall be found resistant to penetration. ADD: No design flaws and no more than a few correctable implementation flaws may be found during testing and there shall be reasonable confidence that few remain. Page 20 Multics Technical Bulletin MTB-Draft 1 UNIX-M Security A1: CHANGE: Testing shall demonstrate that the TCB implementation is consistent with the formal top-level specification. ADD: Manual or other mapping of the FTLS to the source code may form a basis for penetration testing. Subject Sensitivity Labels C1: NR. C2: NR. B1: NR. B2: NEW: The TCB shall immediately notify a terminal user of each change in the security level associated with that user during an interactive session. A terminal user shall be able to query the TCB as desired for a display of the subject's complete sensitivity label. B3: NAR. A1: NAR. Page 21 MTB-Draft 1 Multics Technical Bulletin UNIX-M Security System Architecture C1: NEW: The TCB shall maintain a domain for its own execution that protects it from external interference or tampering (e.g., by modification of its code or data structures). Resources controlled by the TCB may be a defined subset of the subjects and objects in the ADP system. C2: ADD: The TCB shall isolate the resources to be protected so that they are subject to the access control and auditing requirements. B1: ADD: The TCB shall maintain process isolation through the provision of distinct address spaces under its control. B2: NEW: The TCB shall maintain a domain for its own execution that protects it from external interference or tampering (e.g., by modification of its code or data structures). The TCB shall maintain process isolation through the provision of distinct address spaces under its control. The TCB shall be internally structured into well- defined largely independent modules. It shall make effective use of available hardware to separate those elements that are protection- critical from those that are not. The TCB modules shall be designed such that the principle of least privilege is enforced. Features in hardware, such as segmentation, shall be used to support logically distinct storage objects with separate attributes (namely: readable, writeable). The user interface to the TCB shall be completely defined and all elements of the TCB identified. B3: ADD: The TCB shall be designed and structured to use a complete, conceptually simple protection mechanism with precisely defined semantics. This mechanism shall play a central role in enforcing the internal structuring of the TCB and the system. The TCB shall incorporate significant use of layering, abstraction and data hiding. Significant system engineering shall be directed toward minimizing the complexity of the TCB and excluding from the TCB modules that are not protection-critical. A1: NAR. Page 22 Multics Technical Bulletin MTB-Draft 1 UNIX-M Security System Integrity C1: NEW: Hardware and/or software features shall be provided that can be used to periodically validate the correct operation of the on-site hardware and firmware elements of the TCB. C2: NAR. B1: NAR. B2: NAR. B3: NAR. A1: NAR. Test Documentation C1: NEW: The system developer shall provide to the evaluators a document that describes the test plan and results of the security mechanisms' functional testing. C2: NAR. B1: NAR. B2: ADD: It shall include results of testing the effectiveness of the methods used to reduce covert channel bandwidths. B3: NAR. A1: ADD: The results of the mapping between the formal top-level specification and the TCB source code shall be given. Page 23 MTB-Draft 1 Multics Technical Bulletin UNIX-M Security Trusted Distribution C1: NR. C2: NR. B1: NR. B2: NR. B3: NR. A1: NEW: A trusted ADP system control and distribution facility shall be provided for maintaining the integrity of the mapping between the master data describing the current version of the TCB and the on-site master copy of the code for the current version. Procedures (e.g., site security acceptance testing) shall exist for assuring that the TCB software, firmware, and hardware updates distributed to a customer are exactly as specified by the master copies. Page 24 Multics Technical Bulletin MTB-Draft 1 UNIX-M Security Trusted Facility Management C1: NR. C2: NR. B1: NR. B2: NEW: The TCB shall support separate operator and administrator functions. B3: ADD: The functions performed in the role of a security administrator shall be identified. The ADP system administrative personnel shall only be able to perform security administrator functions after taking a distinct auditable action to assume the security administrator role on the ADP system. Non-security functions that can be performed in the security administration role shall be limited strictly to those essential to performing the security role effectively. A1: NAR. Page 25 MTB-Draft 1 Multics Technical Bulletin UNIX-M Security Trusted Facility Manual C1: NEW: A manual addressed to the ADP system administrator shall present cautions about functions and privileges that should be controlled when running a secure facility. C2: ADD: The procedures for examining and maintaining the audit files as well as the detailed audit record structure for each type of audit event shall be given. B1: ADD: The manual shall describe the operator and administrator functions related to security, to include changing the characteristics of a user. It shall provide guidelines on the consistent and effective use of the protection features of the system, how they interact, how to securely generate a new TCB, and facility procedures, warnings, and privileges that need to be controlled in order to operate the facility in a secure manner. B2: ADD: The TCB modules that contain the reference validation mechanism shall be identified. The procedures for secure generation of a new TCB from source after modification of any modules in the TCB shall be described. B3: ADD: It shall include the procedures to ensure that the system is initially started in a secure manner. Procedures shall also be included to resume secure system operation after any lapse in system operation. A1: NAR. Trusted Path C1: NR. C2: NR. B1: NR. Page 26 Multics Technical Bulletin MTB-Draft 1 UNIX-M Security B2: NEW: The TCB shall support a trusted communication path between itself and user for initial login and authentication. Communications via this path shall be initiated exclusively by a user. B3: CHANGE: The TCB shall support a trusted communication path between itself and users for use when a positive TCB-to-user connection is required (e.g., login, change subject security level). Communications via this trusted path shall be activated exclusively by a user or the TCB and shall be logically isolated and unmistakably distinguishable from other paths. A1: NAR. Trusted Recovery C1: NR. C2: NR. B1: NR. B2: NR. B3: NEW: Procedures and/or mechanisms shall be provided to assure that, after an ADP system failure or other discontinuity, recovery without a protection compromise is obtained. A1: NAR. _4 _B_A_S_E _U_N_I_X _S_Y_S_T_E_M _V_, _R_E_L_E_A_S_E _2_._0 _F_U_N_C_T_I_O_N_A_L_I_T_Y File System A UNIX file system is based on a Logical device, rather than a physical device. The physical device is handled by a device driver, which does the physical/logical mapping. The device driver is linked and configured into the UNIX Kernel image. Page 27 MTB-Draft 1 Multics Technical Bulletin UNIX-M Security The file system consists of a SUPERBLOCK, typically starting in sector 1 of the logical device, and disk inodes (dinodes) typically starting in sector 2 of the logical device. The dinodes locate files and their blocks within the file system's logical device. The SUPERBLOCK is padded to the sector boundary. Sectors are typically 512-bytes per block. The disk inodes contain all security and access information for a file, with one dinode per file (inodes start numbering at 1, which is reserved for future use, dinode 2 is reserved for the root directory of the file system). Each dinode indicates: struct dinode { ushort di_mode; /* mode and type of file */ short di_nlink; /* number of links to file */ ushort di_uid; /* owner's user id */ ushort di_gid; /* owner's group id */ off_t di_size; /* number of bytes in file */ char di_addr[40]; /* disk block addresses */ time_t di_atime; /* time last accessed */ time_t di_mtime; /* time last modified */ time_t di_ctime; /* last status change time */ }; Within the file system every file is represented by a dinode, including special files. Special files represent entities such as peripheral devices, block devices, system memory, etc. The use of the dinode to represent special files permits UNIX access control to extend to resources and physical devices. The file methodology also maps a logical resource name and logical resource sub-set to the physical resource, and identifies all information needed by the system to determine device handling procedures and control (including major and minor device identification). Hard links are multiple directory entries referencing the same dinode and are used in the UNIX file system to permit the physical storage indicated by a dinode to be known by a number of names, in one or more directories. This covers the Multics use of add-names and symbolic links (known in BSD UNIX as soft links). Each directory entry has only a 14-character file name and a dinode number within the current file system. The dinode holds a count of the number of hard links which target a single dinode. When removing files, the file space is not physically lost until the last hard link has been removed. Thus a file can be in the storage system, and charged to the original file owner, but be totally inaccessible to that owner. Page 28 Multics Technical Bulletin MTB-Draft 1 UNIX-M Security System V, release 2.0 permits a file owner, or the superuser, to change the current ownership of a file to any other user (this may require security restriction). Disk accounting is done on the basis of the file owner, rather than the hierarchy which contains the file (as in Multics). Access Control Model UNIX access control is done through read, execute and/or write permission, represented by 3-bits, for each of three logical user groupings, the owner (as identified by di_uid), members of the owner's group (as identified by di_gid) and all other users of the UNIX system. Access control is checked whenever files are opened and owner and group validations are checked against the effective UID and GID. The real UID and GID are set to the UID and GID of the user responsible for the creation of the process. The effective UID and GID are used to determine access and are equal to the process's real user ID and real group ID respectively, unless the process or one of its ancestors evolved from a file that had the set-user-id or set-group-ID bit set. Read and write permission are checked when opening files under program control, execute permission is checked when the Kernel is opening the file to read it to the user's core image. It is possible to have real execute-only programs supported under UNIX, since the Kernel will permit the program to be executed and the core image read by the code, but prevents a program from opening the file for file IO. For directories, read permission permits a program to open a directory as a file for reading, write mode for a directory permits a user to create files in the directory (a program cannot open a directory as a file in write mode), execute mode (search) permits the kernel to search the contents of the directory to find a file (even if read permission is not granted). If search permission is not granted a user at some level of the hierarchy, that is as far down the file system as the user can see. For example, a user with only read access on a directory can list the directory information, but cannot access the contents of the directory. Access to special files is controlled through the normal owner/group/other access mechanism, thus controlling access to terminals, tapes and other peripherals. When a user logins in to the system access on the login terminal is set to permit the user to perform IO on it. When a user Page 29 MTB-Draft 1 Multics Technical Bulletin UNIX-M Security requests a tape drive, access is set to permit IO on the tape drive. User Verification and Login A multi-user UNIX system has all terminals connected to a getty routine, which sends a banner message and waits for a login response. When a user wishes to log into the UNIX system a login name and password are required. (It is possible to have a null password and not be prompted for a password.) The login name supplied is validated against the /etc/passwd file, the password is validated against the encrypted password found in the same file, for that login name. If the login identification is sucessful, the same passwd file entry is used to determine the real User ID (UID) and real Group ID (GID) for the user. A working directory and shell program are determined for the user, and the shell is started by the getty task EXECing it. At this point the user has been completely identified and logged in. User validation information for the login session is set through the act of the login routine, which runs with an effective UID of ROOT, doing a SETGROUPID and SETUID system call, which changes the real and effective GID and UID to that of the logged in user. SETUID and SETGROUPID A task's access limits are defined by its current effective UID and GID. These can be altered through the execution of a program with a SETUID or SETGID mode flag, in which case they are set to the UID and/or GID of the owner of the program being executed. Thus the program executes with the same file access permissions as if it were being executed by the owner of the program, rather than the real UID and GID. They can also be altered through SETUID and/or SETGID system calls, which change the effective and real UID and GID, if the current effective UID is ROOT. This means that any program which has a SETUID mode, and is owned by root, may reset user access validation information to any UID and GID it desires, just as if the user had been revalidated by a login. Thus ROOT UID is extremely powerful and all SETUID programs owned by ROOT are essentially part of the TCB. The SETUID mode flag can be set by the owner of a file (or the SUPERUSER), and is cleared by operations which would otherwise change the owner UID or GID of the file. It is possible to build trojan horse programs which plant a WINDOW into a user's file space. User A has a program which user B executes, which creates a program in user B's hierarchy, owned by B and with a SETUID set. User A may execute this program, which will run with user B's access and give B's access to A. Page 30 Multics Technical Bulletin MTB-Draft 1 UNIX-M Security A route around this trojan planting is to only permit a SETUID mode for a file to be set if: the effective UID is ROOT or the effective UID is the same as the UID of the owner of the program making the CHMOD request and the UID of the file owner. In the example above, since A's program is running with an effective UID of B this check prevents it setting the SETUID mode on the trojan it is planting, thus A cannot run the trojan to get B's access. Message Queues UNIX supports an inter-task message facility, where tasks can connect themselves to or create system wide (as well as task specific) message queues. Messages can be sent to and received from the queues on the basis of queue keys and permits a communication method not directly mirrored in Multics, where use of the message facility requires known and specific message queues to be created by users and managed by the system. In this case the message queue identification requires knowledge of the location of the message queue segment within the hierarchy. In the case of UNIX, the message queue is a system wide - per bootload queue, managed for the user within a system area. Inter-Process Communication UNIX utilizes a semaphore system to implement inter-process signalling. With it a task connects to a semaphore and either sets the semaphore, waits for it or determines the current state of the semaphore. This is a blocking protocol which wakes a process waiting for the semaphore. If the task wakes due to another signal being received, a value of -1 is returned, otherwise the semaphore was received. Semaphores use the same access mode settings as file system objects, but are not in the file system. Shared Memory UNIX permits tasks to share memory between them, and to map this shared memory into their address spaces at an address selected by the user or at an address selected by the system. The user may select either an arbitrary address within his address space, or an shared memory block (considering the address space to be blocks of SHMLBA bytes in length, the address selected will be the floor address of the block the supplied address lies in). Page 31 MTB-Draft 1 Multics Technical Bulletin UNIX-M Security _5 _B_A_S_E _U_N_I_X _S_Y_S_T_E_M _V_, _R_E_L_E_A_S_E _2_._0 _C_O_M_P_L_I_A_N_C_E _T_O _C_R_I_T_E_R_I_A UNIX, as produced by AT&T is rated in each of the requirements listed above, and the predicted resultant classification indicated, with the rationale for the classification. Audit UNIX currently fits at best in the C1 category, since it has not audit trail facilities. Configuration Management UNIX would currently be potentially capabile of a B2 rating, since it supports the Source Code Control System (SCCS) and Programmer's Workbench facilities. Covert Channel Analysis UNIX would currently be capable of a B1 rating, since there is no covert channel analysis. Design Documentation UNIX would currently be capable of only a D rating, since there is no protection philosphy documentation available with the system. Instead protection information is scattered throughout all documentation in various and incomplete forms. Design Specification and Verification UNIX would currently be capable of only a D rating, since Design Documentation does not exist. Device Labels UNIX would be capable of a B1 rating, since Device Labels are not required til B2. Discretionary Access Control UNIX would be capable of a C1 rating. A C2 rating requires discretionary access exclusion "to the granularity of a single user". Exportation of Labelled Information UNIX would be capable of a C2 rating since this does not require labels. Exportation to Multilevel Devices UNIX would be capable of a C2 rating since this does not require labels. Page 32 Multics Technical Bulletin MTB-Draft 1 UNIX-M Security Exportation to Single-Level Devices UNIX would be capable of a C2 rating since this does not require labels. Identification and Authentication UNIX would be capable of a C2 rating. A B1 rating would require mandatory access identification. Label Integrity UNIX would be capable of a C2 rating since this does not require labels. Labeling Human-Readable Output UNIX would be capable of a C2 rating since this does not require labels. Labels UNIX would be capable of a C2 rating since this does not require labels. Mandatory Access Control UNIX would be capable of a C2 rating, since it does not require mandatory access control. Object Reuse UNIX would be capable of an A1 rating, since it only assigns zero filled disk blocks and memory frames. Security Features User's Guide UNIX would only get a D rating, since no such guide exists. Security Testing UNIX would only get a D rating, since no documentation exists to test against. Subject Sensitivity Labels UNIX would receive a B1 rating, since it does not require notifying the user of each change in the security level associated with that user. System Architecture UNIX would receive a C1 rating, since it maintains a distinct domain for the Kernel, as opposed to the user. It cannot receive a C2, since this requires enforcement of a non-existant auditing. System Integrity UNIX would receive a D rating, since there are no features to validate correct security operation of on-site hardware and firmware elements of the TCB. Page 33 MTB-Draft 1 Multics Technical Bulletin UNIX-M Security Test Documentation UNIX would receive a D rating since there is no security functional testing. Trusted Distribution Not required til A1 rating, thus UNIX gets a B3 rating. Trusted Facility Management UNIX gets a B1 rating. B2 requires a separate operator and administrator function. Trusted Facility Manual UNIX gets a D rating. There is no substantive documentation presenting cautions. Some information is available, but is only about 1/2 page in length and not comprehensive. Trusted Path UNIX gets a B1 rating since the login procedures are not essentially part of the TCB as UNIX is supported. Trusted Recovery UNIX gets a B2 rating, since this does not require a trusted recovery. The minimum category seen above limits a stock UNIX system to a rating of D, esentially meaningless, in terms of security. _6 _U_N_I_X_-_M _D_I_F_F_E_R_E_N_T_I_A_T_I_O_N _F_R_O_M _S_T_O_C_K _U_N_I_X UNIX-M is substantially different from stock UNIX in terms of its implementation, and does not have the same intimate connection to the hardware. Since it depends upon the host operating system (Multics) for peripheral support, scheduling and process environment protection, it essentially INHERITS a number of security features not present with a stock UNIX system, thus removing a number of the restrictions seen above. Three basic alternatives for the implementation of UNIX, or a UNIX look-alike, are available. UNIX Port This is a simplistic porting of most UNIX functions to execute in a UNIX specific environment hosted within a Multics system. UNIX tasks would utilize distinct Multics processes, created for UNIX but scheduled by Multics. Device access would permit multi-task access to terminals and tapes. The UNIX Page 34 Multics Technical Bulletin MTB-Draft 1 UNIX-M Security file system would be implemented through the use of Multics segments within a Multics file system. UNIX's interpretation of these segments would implement a UNIX file system, with UNIX access control. Each UNIX task would consist of the user task image, with its data, and the Kernel image, with common storage segments to permit Kernel-Kernel communication amongst all UNIX tasks of that UNIX machine. Within the Multics process the UNIX system would utilize a set of absolute segment numbers to base its databases and user information upon. This permits easy process duplication and removes any need for dynamic linking to occur within the UNIX user task space. It permits multi-segment execution objects to be created by the linkage editor and executed in a simple and direct manner. In this model UNIX would not recieve better than a D rating, but the hooks placed into Multics for UNIX hosting support would be rated to the full B2 rating (if UNIX were not in use). Thus a B2 secure site could remain B2 secure by not utilizing UNIX. B2 UNIX This alternative is a superset of the simple UNIX Port. It requires a large design and documentation effort for cover areas of security design not inherited from Multics. It creates its own TCB, which must be B2 rated, thus changing the implementation modularization of standard UNIX. Most importantly it MUST redefine certain UNIX features to enable B2 compliance, thus it runs the risk of not being termed "UNIX", and having potential program porting problems. The major risk inherent in producing a B2 UNIX is per-se the work involved to make it come off, or the redesign of the UNIX KERNEL and its functions. It is primarily the risk that the UNIX so produced will not be acceptably a UNIX system. This could produce a system which might only be marketable as UNIX-like, or one in which there would be sufficient suprises and mal-functionality in important areas that it receives very poor review by the user community. Ersatz-UNIX This alternative is the support of UNIX functionality mapped into a native Multics environment, utilizing a new Multics feature Control Point Manager (CPM), to support task creation and management. This alternative runs Multics Page 35 MTB-Draft 1 Multics Technical Bulletin UNIX-M Security native code, from all Multics language processors, and runs them in a normal Multics environment, with a separate area.linker and stack per generated task. At this time there is no time slicing feature in CPM, and all tasks will run with common KST, PDS, search rules and segments. There is no memory protection from one task to another. Since it utilizes native Multics code, requiring only slight TCB extensions and a UNIX runtime library, it is the fastest method to attain a functional environment. It does have noticable differentiations from a REAL UNIX environment which may remove it from consideration, depending upon market desire determination. These three alternatives will be expanded upon in greater detail, and specific security aspects developed. _7 _M_U_L_T_I_C_S _M_O_D_I_F_I_C_A_T_I_O_N_S _F_O_R _U_N_I_X _S_C_E_N_A_R_I_O_S _7_._1 _U_N_I_X _P_o_r_t The UNIX port affects a number of security aspects. System Architecture The UNIX port affects terminal access, by requiring multi-process access to terminals, arbitrated by the Kernel. This action requires the existing Multics hardcore to permit a specified set of processes to access a terminal. This is indicated to the hardcore through the use of a tty_group_id, which is the same as the wtce.uproc of the process owning the terminal. This tty_group_id is set at the time of process creation and may be cleared at the request of the process. If the value is not set then no extra access above the current is permitted. The value is stored in the pds of the process attempting access, and must match wtce.uproc to be valid, thus simple garbage values will not match. This value can only be set through the action of a specific UNIX process creation, thus if UNIX is not on the system it will remain unset and access will be as normal. No additional work is to be done at this time to handle event processing specific to multi-process access to a Page 36 Multics Technical Bulletin MTB-Draft 1 UNIX-M Security resource. Thus the UNIX terminal owner (the dial_manager for UNIX) must handle the whole IO, or use an event-call channel to receive block completions and signal the UNIX tasks as appropriate. Thus the owning process remains the arbiter of access and knowledge of use. Access is only granted within the same category and access class, since not AIM check modification to the standard is done. This policy change must be documented, tested for and included in the architecture of Multics through the B2 level. The same requirements are in force for extension to permit multi-process access to tape drives, if tape access is to be permitted to UNIX. (This may not be an initial UNIX imperitive, terminal access is such an imperitive.) Identification and Authentication UNIX must be extended to have a Kernel primitive to the complete login and process creation, thus changing basic UNIX architecture which previously did these actions through user level programs with the ROOT setUID. Process identification and creation must be a trusted path facility, which is assured through the action of disconnection and dialing to the UNIX dial server. The login process validates against the Multics personid/projectid database, and sets process identification and validation information according to this database, rather than any UNIX specific database. Thus process Identification and Authentication remains part of the Multics TCB, and not the UNIX Kernel. The UNIX user will be unable to change passwords in mid-session, and must do it at login. This is another UNIX change, but minor in nature and required to match security criteria through the B2 level. These changes should be sufficient to provide a support base for a UNIX implementation, which has its own separate and distinct file system, does not have access to the Multics file system, such that the support base, divorced from the UNIX Kernel, does not violate B2. Page 37 MTB-Draft 1 Multics Technical Bulletin UNIX-M Security _7_._2 _B_2 _U_N_I_X A B2 UNIX implementation is similar to the simple UNIX port noted above, it is divorced from a number of the limits which impede getting a higher rating for a normal UNIX system, and inherits quite a bit of security from Multics direct management of resources. What must be provided in this case however is still rather extensive, and is itemized below. Audit B2-UNIX-M will require audit facilites to be installed to indicate UNIX specific access to file system objects. This audit mechanism is needed rather than simply relying upon the present Multics audit, since UNIX will have a many to one correspondence between directory entries and dinodes through the use of hard links. Such a functionality is preformed in Multics through soft links and add-names and it is always possible to indicate the final real target. The UNIX audit should indicate the link path used, and the dinode number (the final real target). All other functions may require UNIX specific auditing, such as program initiation, etc. Configuration Management B2-UNIX-M would utilize Multics' Configuration Management system. NOTE. We may be required to distribute source of all security relevant sections of UNIX to accomplish this requirement. This could prove a licensing problem. Covert Channel Analysis B2-UNIX-M will require covert channel analysis. This may however totally inherit such capabilities from Multics, since Multics is still the aribiter and manager of the physical communications channels (comm, disk, tape and page fault). Design Documentation B2-UNIX-M will require a complete protection philosophy document which details its design and implementation of protection. This philosophy and documentation should mesh directly with the existant Multics documentation as an addendum and should indicate all deferrals to existing Multics protection mechanisms. Page 38 Multics Technical Bulletin MTB-Draft 1 UNIX-M Security Design Specification and Verification B2-UNIX-M requires Design Documentation, as per above. THis should include specification and verification sections. It must mesh with existing Multics specification. Device Labels B2-UNIX-M would inherit Multics' Device Labelling, and hence its B2 capabilities in this area. Design info must indicate that all device labelling is performed by Multics and unalterable by UNIX-M. Discretionary Access Control B2-UNIX-M would utlize Multics' discretionary access control mechanisms, and not alter them. This permits it to utilize ACL's internally to enforce access control exclusions permitting a C2 and above compliance. This will be an extension to UNIX to permit the higher rating. The portion of UNIX-M which enforces user access controls within the UNIX system would have to be part of the Multics TCB to get a B2 rating. SETUID and SETGROUPID must be figured into this access control and into the systems architecture. Exportation of Labelled Information B2-UNIX-M would inherit all Mandatory access control and labelling. Exportation to Multilevel Devices B2-UNIX-M would inherit all Mandatory access control and labelling. Exportation to Single-Level Devices B2-UNIX-M would inherit all Mandatory access control and labelling. Identification and Authentication B2-UNIX-M would inherit all Mandatory access control and labelling. It would require user identifcation and authentication to be part of the TCB and to perform all processing as for current process identification, creation and authentication. In addition it must setup the UNIX-M environement necessary to start the UNIX task at the same point as the parent. The use of SETUID and SETGROUPID and ROOT access should be considered as part of this identification and authentication. Its philosophy must be considered. Label Integrity B2-UNIX-M would inherit all Mandatory access control and labelling. Page 39 MTB-Draft 1 Multics Technical Bulletin UNIX-M Security Labeling Human-Readable Output B2-UNIX-M would inherit all Mandatory access control and labelling. Any explicit line printer functions will be provided through Multics and thus inherit Multics' current and future labelling standards. Labels B2-UNIX-M would inherit all Mandatory access control and labelling. Mandatory Access Control B2-UNIX-M would inherit all Mandatory access control and labelling. Object Reuse b2-UNIX-M would utilize Multics for disk and memory support thus inheriting zeroing of newly created information. UNIX-M must ensure that all segments returned to any common segment pool used by it for internal purposes are truncated immediately upon return to enforce data deletion. Security Features User's Guide A B2-UNIX-M guide must be generated, to indicate all features and cautions. Security Testing B2-UNIX-M security must have a test plan and undergo functional and stress testing. This would be part of a complete Multics re-test, which would be required due to Multics TCB changes. Subject Sensitivity Labels B2-UNIX-M would inherit sensitivity labels and madatory access control from Multics. System Architecture B2-UNIX-M architecture will inherit many features through Multics, such as resource protection (amended by multi-process usage) and auditing. Additional auditing provided for UNIX object access must pass B2 architecture constraints. The use of distinct Multics processes for processes inherits Multics' process management and control for B2. The use of lower rings for the UNIX Kernel and UNIX Kernel TCB statisfies the requirements for settings a safe domain for the TCB. Structuring the UNIX Kernel into distinct modules, with known security implications and functions, and separating security and access control functions from basic non-security support of UNIX will not only provide B2 compliance, but will definitely make a more Page 40 Multics Technical Bulletin MTB-Draft 1 UNIX-M Security solid product. Segmentation is not only used, but at the heart of the implementation. System Integrity B2-UNIX-M totally inherits all system integrity features and provides none of its own. Test Documentation There must be test documentation and a test plan, including covert channel analysis. Trusted Distribution This is totally inherited from Multics. Trusted Facility Management Operator and administrator functions will be provided through native Multics, rather than through native UNIX and will be distinctly separated. function. Trusted Facility Manual Such a document must be generated through the requirements of the B2 level. It will borrow strongly from the existing Multics documentation and will be an appendum to the Multics documentation. Trusted Path B2-UNIX-M will provide a trusted communication path through the same methodology as Multics currently does, line disconnection and reconnection. The login procedure will be a trusted communication and will be the only point at which password changing can occur. Trusted Recovery B2-UNIX-M inherits this from Multics, since it does not do its own recovery. This is provided through the Multics system recovery features already in place. At most UNIX need only provide a function to compare directory/dinode access information with the ACL set for the UNIX files (which is considered the master information). Several design features of UNIX will require modification and/or replacement to comply with B2 requirements, as noted above. This modification should be as close as possible to the original intent or current usage to reduce the possibility of serious compromise of expectations. Page 41 MTB-Draft 1 Multics Technical Bulletin UNIX-M Security _7_._3 _E_r_s_a_t_z_-_U_N_I_X _C_o_n_c_e_p_t _D_i_f_f_e_r_e_n_t_i_a_t_i_o_n Ersatz-UNIX attempts to exploit existant Multics features to implement a UNIX sub-system for Multics. This implementation uses a new Multics feature, Control Point Management, and requires additional user ring support libraries to be written for UNIX-like support. It will require TCB addiditons for some inter-communications and data sharing, but these do not affect existant TCB code, and are additions to the TCB. One of the desires for Ersatz Each login instance will be represented by a single Multics process, which will use CPM to produce sub-tasks, corresponding to the UNIX tasks which a login instance might generate. Some UNIX functionality is unrecoverably lost, since it would be unsupportable in this environment. Address Separation Since all UNIX tasks for a login session execute within the address space of a single Multics process there is a great deal of task environment which is directly shared between tasks. Each task can be given its own stack and area.linker as a function of CPM, but all other segments are shared, as is the KST. Thus it is possible for one UNIX task to violate another's address space, either intentionally or by accident. This would appear to be in direct conflict with B1 criteria 3.1.3.1.1 in System Architecture. The TCB shall maintain a domain for its own execution that protects it from external interference or tampering (e.g., by modification of its code or data structures). Resources controlled by the TCB may be a defined subset of the subjects and objects in the ADP system. THE TCB SHALL MAINTAIN PROCESS ISOLATION THROUGH THE PROVISION OF DISTINCT ADDRESS SPACES UNDER ITS CONTROL. The TCB shall isolate the resources to be protected so that they are subject to the access control and auditing requirements. Execute Only Environment Since the tasks will execute as normal Multics procedures, which are known in the process' address space for the extent of the login session (unless explicitly terminated), all routines which can be executed are inherently open for abuse. A regular UNIX system, and the first two Page 42 Multics Technical Bulletin MTB-Draft 1 UNIX-M Security alternatives do not have this problem, since the only program which can access the execute only information in a manner to read it, is the program itself looking at its memory image. All other file access is constrained by the access control of the UNIX Kernel. SETUID/SETGROUPID UNIX tasks can make use of access limits which are carried with the object to be executed, imported from the owner of the object. For example the mkdir and rmdir commands execute as if the ROOT were executing them, and import the ROOT's access to file system objects. Such a feature is used for securing information to be specific to a file handler, such as INGRESS, and cannot be duplicated within a norml Multics system and thus must be lost in ersatz-UNIX. Hard File System Links The System V, release 2.0 UNIX has the equivalent of a VTOCE for each file, termed a dinode (Disk INODE), which is referenced by its index in an array of such dinodes within the file system's SUPERBLOCK. All directories within that file system contain entries consisting only of a 14-character entry name, and a two-byte dinode index. Thus many directory entries can point to a single file (dinode). The dinode itself has a link count, all owner and access information, and indicates where file information is stored. If a file entry in a directory is deleted, the directory entry is removed, and the link count in the referenced dinode is decremented. When it becomes 0 the file information is physically deleted. Thus the owner of a file can delete it, but the file itself is still known and available to other users who have linked to it. The owner continues to pay for the storage. Multics cannot emulate the deletion action, nor the re-assignment of a file ownership. Thus UNIX programs, which might make use of the creation of a file and linking to it from another location then deleting the original name, will find that the file itself actually disappears. This action could be modified by a runtime file management system working on behalf of the UNIX routines, but Multics routines, calls to Multics primitives or other actions could produce unpleasant suprises. In addition a parallel file management technique would need to do information hiding and would potentially be considered as a TCB extension. Concurrent Execution of Tasks The CPM product currently only does task switches on a requested process block. This would not necessarily provide a means to multiplex the process amongst the UNIX tasks, and Page 43 MTB-Draft 1 Multics Technical Bulletin UNIX-M Security situations of background task usage for computationally intensive operations, such as compiles, would result in no terminal response for extended time periods. Thus CPM would need to be extended with a multiplexing method to provide an acceptable service. Multics/UNIX Concept Conflicts One could liken the differences between Multics and UNIX as the difference between a continuous simulation and a discrete simulation system. This comparison basically shows that UNIX executable objects are completely know at Link Edit time, the only variables in their execution environment are the files of the file system and the user executing the program, a very discrete and known condition for execution. Multics however continually builds its execution environment outside the control and knowledge of the implementer of the code. Search rules, initiated segments, the current working directory, dynamic link formation from character strings and the concept of the login session being a single program execution, such that external variables and static information is only initialized once per session, rather than once per program execution, all combine to produce greatly different expectations and system implementations between UNIX and Multics. All these problems have been noted many times when users have ported systems from classic computing architectures to Multics. Ersatz-UNIX will have the same problems when porting programs from normal UNIX. This does not indicate that Multics does not offer a great deal of power, or that features such as external static variables cannot be used more effectively to pass information between separate programs than files. It does indicate that there are many inescapable differences which collide head on with UNIX programmer expectations and implementations, and will produce porting problems. It is doubtful that Ersatz-UNIX could be marketed as being UNIX compatable, rather than a UNIX-like subsystem within Multics. _7_._4 _E_r_s_a_t_z_-_U_N_I_X _S_e_c_u_r_i_t_y _R_e_q_u_i_r_e_m_e_n_t_s Ersatz-UNIX will essentially adopt almost all security aspects directly from Multics, since it is a Multics process. Access control, both mandatory and discretionary are essentially provided by Multics, thus permitting B2 to be inherited. Certain areas might require additional workup for security considerations. Page 44 Multics Technical Bulletin MTB-Draft 1 UNIX-M Security Audit If a file system mirror operation is done to support the use of hard links then auditing must be performed in some fashion to handle the deletion of an object, and this must be part of the TCB. Covert Channel Analysis There may be covert channel implications in a multi-class UNIX system through file system mirror operations. Design Documentation UNIX system design should be detailed, with security considerations and implications. Discretionary Access Control If file mirroring is occuring there may be implications to Discretionary Access Control through the hiding of deleted files. System Architecture Consideration must be made to the philosopy of the UNIX support. If it is support of a multi-tasking environment in which each task is a different environment (as the current UNIX philosophy), then Ersatz-UNIX violates B1 criteria. If the Multics concept of multiple parallel procedure execution within a single process is acceptable, then we may violate UNIX criteria sufficiently to provide suprises for the user, and to no longer be able to sell our system as a UNIX system. Test Documentation Must be provided to cover all system aspects. In addition, support of inter-process communication, shared memory and message traffic will require additions to the TCB and must be accounted for in all aspects of B2 compliance. Ersatz-UNIX will definitely be a faster way to have an environment with a number of UNIX or UNIX-like features. However one needs to determine the value of a close UNIX compliance, and exactly how much we are value adding to a Multics C environment to determine if Ersatz-UNIX is a viable alternative. Page 45 MTB-Draft 1 Multics Technical Bulletin UNIX-M Security _8_._1 _A_c_c_e_s_s _C_o_n_t_r_o_l UNIX access control is done through an owner/group/other grouping of users. The owner is identified by an indirect method, utilizing a password file with a User Identification value encoded as characters. Each disk inode (dinode) has an owner value encoded as a bit value. It is possible for more than a single user name to have the same UID, and for the UID assigned to be changed through an editor slip such that the user logging in no longer owns any files, nor has access to them, including the normal home directory. There is no assurance that the user name used is tightly bound to the file and process ID. This will be a potential security problem, which is best alleviated through the tight binding of the users login name and the process identifcation value, i.e. the user name is the process identifcation value. The group id is handled in exactly the same fashion as the UID, using the file /etc/group. It is also a loose binding which could be tightened up through use of a group name as the groupID. All access goes through the dinode access control, in which the dinode has 9-bits allocated in three groups of 3-bits (read, write, execute). The three groups define the access granted to users with a UID matching the owner UID in the dinode, the access granted to users with a GROUPID matching the owner GROUPID in the dinode, and the access granted to all other users of the UNIX system. There is no method to exclude individuals, other than the owner of the file, since there is not category of individuals, other than the file owner. _8_._2 _M_u_l_t_i_c_s_/_U_N_I_X _C_o_n_c_e_p_t _C_o_m_p_a_r_i_s_o_n_s 8.2.1 THE LOGIN INSTANCE. The Multics view of a login instance is that of a single schedulable entity, termed the process. The UNIX view of a login instance is that of a login session which may exist through the creation, execution and destruction of a number of distinct tasks, each separately scheduled and controlled, and capable of being simutaineously executed. Page 46 Multics Technical Bulletin MTB-Draft 1 UNIX-M Security The UNIX task concept provides a controlled isolation between tasks. The initial environment of the originating task is essentially duplicated into the environment of the child task (some portions may be omitted as explicitly requested by the originating task). After this point the tasks run as totally isolated entities, sharing data only upon explicit program request by both tasks. The Multics process concept provides a time extended execution environment which could theoretically include ALL data existant upon the total storage system of the computer, and which is dynamically alterable, in terms of both data and executing code. Within the UNIX environment, ALL internal data linkages are determined at a linkage edit time, which preceeds and is distinct from the execution time. Within the Multics environment, linkage of code may be predetermined and linkage of data may be predisposed by a binding stage (equivalent to a linkage edit). Linkage and creation of external static data areas is always done at execution time utilizing dynamic linkage resolution mechanisms. Semantics should be determined at this point. PREDETERMINED code linkages are done between code modules bound into a single executable segment. They are predetermined because the code actually exists within the segment and thus connections can be determined and code altered accordingly. PREDISPOSED data linkages exist only as potential linkages, there is no data space reserved until the linkage is used at execution time, a hardware fault occurs which is interpreted by the software, and the storage space is reserved and linked to by the runtime support routines. These two views produce a different end-product for the end-user since the UNIX user exists in a predetermined and deterministic environment which cannot be easily altered from underneath, except by the owner of the environment (package). The Multics environment is dynamically created by the execution of a process through an extended time period, and is suceptible to change by an outside agency even as it executes. Thus it is potentially highly indeterministic. This deterministic/non-deterministic environment shows itself in two basic ways. 1. A Multics user tailors his "name space" to avoid conflicts within the extent of the login instance. This means providing unique names for routines which will be Page 47 MTB-Draft 1 Multics Technical Bulletin UNIX-M Security dynamically envoked, object binding to provide name hiding, avoidance of duplicate external static variable names (i.e. Fortran common) and care taken to determine search rules which will be utilized. 2. A UNIX user tailors a system at the point it is to be linkage edited, and ensures unique external names within the edited object. After the linkage edit stage the environment of the edited object has been completely determined and will not be altered, except by changes of the KERNEL interface and/or specifications. It can thus be easier to create and maintain programming systems within the deterministic UNIX environment than the dynamically linked Multics environment. The typical problems encountered by users moving to a Multics environment are the suprises from having external static variables existant long after the program which created them has ceased to execute, producing a conflict within a currently executing program. Re-initialization of external and internal static variables is also done only once in a login instance, unless explicitly requested during the login instance. With a UNIX environment, each envokation of an object provides a fresh re-initialization of static data areas. Psychologically programmers tend to re-utilize existing code, favourite variable names and essentially duplicate known and working systems, by making only necessary minor modifications to produce a new functionality. This tends to produce problems in the Multics environment, since duplication of dynamic name information within the timespace of the login instance can produce totally unexpected results, which cannot be easily planned for. Multics has not fully addressed the problems created by its dynamic environment, but has attempted some solutions. RUN units are used to attempt to provide a fresh environment for a command to be executed, and to remove the effects of that command on the dynamic environment after its termination. Binding is used to avoid code name space conflicts and to merge initialization and size determination of external static variables. Both are needed to avoid conflicts which would occur if this information were not predetermined before actual execution. They still however fall short of the desires and requirements of a number of packages and programmer desires. But other problems still exist through the use of Search Rules to find executable objects and the name space of the Known Segment Table. Page 48 Multics Technical Bulletin MTB-Draft 1 UNIX-M Security 8.2.2 USER IDENTITY In Multics, and throughout its TCB's access control, the identity of a user is determined through the use of character strings to identify the personid, the projectid and the tag (type of execution, interactive (a), daemon (z) or absentee (m)), and ACL checking is done against an access control name held in the process's PDS. In UNIX the identity of a user is determined through two numeric fields held in registration files under the control of the ROOT. The two files /etc/passwd and /etc/group each contain strings which hold a number of registration fields. An example of an /etc/passwd entry is: tgo:password encrypted here:29:101:Tom Oke:/c/tgo:/bin/csh In this example the user name is "tgo", the userid is 29, the groupid is 101, a text field for accounting purposes is "Tom Oke", the initial working directory is "/c/tgo" and the initial shell program is "/bin/csh". For each groupid there must be a corresponding entry in the /etc/group file in the form: c::101:tgo,dkr In this example the group name is "c", the password for the group is null and the groupid is "101". The last set of comma separated fields are the login names which may use the "newgrp(1)" command to become a member of the group, even though they did not initially log into the group. This identification system utilizes a completely different mechanism than the Multics Access Control List, and which does not directly map into the ACL list, since there is no known correspondence between the contents of the /etc/passwd, /etc/group files and the Multics acounting databases of the SAT, PNT and PDT. 8.2.3 USER VALIDATION A UNIX task is essentially identified by its effective UID and GID. These can be altered by SETUID and SETGID programs, which do not alter the real UID and GID, or by the execution of the Page 49 MTB-Draft 1 Multics Technical Bulletin UNIX-M Security SETUID and/or SETGID Kernel functions. Programs running with an effective UID other than ROOT can set their GID and UID back to the real UID and/or GID, which matches their initial validation. However programs running with an effective UID of ROOT can set their real and effective UID and GID to anything desired, thus changing the task access validation and identification. This is indistinguishable from logging in as the new user (and in fact is the way in which a normal UNIX login sets up the UID and GID for the login session). Thus all programs which have SETUID priviledge and are owned by ROOT are essentially part of the TCB, for this reason, as well as the reason that they circumvent most other restrictions. For UNIX on Multics, the Multics process validation and identification will be determined by a system call which logs in the user, and performs all validation, identification and process creation. This validation will not be altered by SETUID or SETGID system calls (at least in the UNIX Port). In a full B2 compliant implementation it may be possible to change the task's identity in this fashion, but the ability to set a SETUID and/or SETGID priviledge on a program must be highly secure, or limited entirely to ROOT. _8_._3 _C_o_n_c_l_u_s_i_o_n This paper has presented some of the opening ideas as to security issues in the implementation of a UNIX system on Multics. It is not exhaustive, but is hopefully essentially correct. Further analysis and development is mandatory before the issues can be resolved and design begun.