MULTICS DESIGN DOCUMENT MDD-002 To: MDD Distribution From: R. Michael Tague Date: August 1, 1985 Subject: Multics Security Model - Bell and LaPadula Abstract: The Multics system enforces a security policy that is an implementation of the security model described by Bell and La Padula. This Multics Design Document (MDD) presents the relationship between the actual implementation in Multics and the model. Revisions: REVISION DATE AUTHOR initial 85-06-01 Benson I. Margulies 01 85-08-01 R. Michael Tague _________________________________________________________________ Multics Design Documents are the official design descriptions of the Multics Trusted Computing Base. They are internal documents, which may be released outside of Multics System Development only with the approval of the Director. - i - MDD-002 Multics Security Model CONTENTS Page Introduction . . . . . . . . . . . . . 1 Multics Objects . . . . . . . . . . . 1 Segments . . . . . . . . . . . . . 1 The ROOT Directory . . . . . . . . 2 Directories . . . . . . . . . . . . 2 Message Segments . . . . . . . . . 2 Messages . . . . . . . . . . . . . 3 Non-system I/O Devices, Disk and Tape Volumes . . . . . . . . . . . 3 Communication Channels . . . . . . 4 System Disk Volumes (Logical Volumes) . . . . . . . . . . . . . 4 Processes (Interprocess Communication) . . . . . . . . . . 5 Multics Subjects . . . . . . . . . . . 5 Processes . . . . . . . . . . . . . 5 Multics Access Control - Its Relationship with the Model . . . . . 6 Discretionary Access - Access Control List Matching . . . . . . 7 Mandatory Access Control - Security Label Comparison . . . . . . . . . 8 Object Access Modes - Their Correspondence to the Model . . . . . 9 Segment Access Modes . . . . . . . 9 Directory access modes: . . . . . . 10 Message Segment extended access modes: . . . . . . . . . . . . . . 12 RCP access modes: . . . . . . . . . 14 Logical Volume access modes: . . . 15 Communication Channel access modes 15 Process access modes . . . . . . . 16 Directory Visibility and the Compatibility Axiom . . . . . . . . . 16 ii Multics Security Model MDD-002 _I_N_T_R_O_D_U_C_T_I_O_N Bell and La Padula's "Unified Exposition"(1) describes the Bell and La Padula formal model of computer system security. Section III of the report described the correspondence between the model and the Multics system of the time as they understood it. This MDD describes the correspondence between the Bell and La Padula model and Multics as it exists today. We describe the Multics Objects, e.g., segments, directories, and message segments, the Multics Subjects: the process, the access modes that Multics defines for these objects, and we describe how each Multics access mode corresponds to a Bell and La Padula access mode. We show how the four system state variables of the model: current access set, access permission matrix, level function, and hierarchy are represented in Multics structures. We further show how access to each object respects the five axioms of the model: Compatibility, Tranquility, Activation, Simple Security, and the *-property. Throughout this report the Bell and La Padula model will be referred to as the B&L model or simply the model. _M_U_L_T_I_C_S _O_B_J_E_C_T_S This section lists all the Trusted Computing Base protected (TCB) objects, identifies the software that controls access to the object (resource), describes where their discretionary (ACL) and mandatory (label) access control attributes are stored, describes how the security label of the object is set and to what levels the security label may be set so as to maintain the compatibility of the hierarchy (H) in the sense of the compatibility axiom of the model, describes the creation and destruction or activation and deactivation of objects (Activation axiom). Once set, the security label cannot be changed except by privilege or by returning the object to the system (unassignment for devices and communications channels, release and clearing for volumes, deletion for all other objects). This insures the tranquility of the hierarchy (tranquility axiom of model). _________________________________________________________________ (1) Bell, D. E. and La Padula, L. J. , Secure Computer System: Unified Exposition and Multics Interpretation. ESD-TR-75-306, Mitre Technical Report MTR-2997 Rev. 1, March 1976. 1 MDD-002 Multics Security Model _S_e_g_m_e_n_t_s Segments are containers for information. Segments can also be used as access control objects by associating a specific segment (and its ACL) with another object. Segments are managed by the "file system" in ring zero. The ACL is stored in the containing directory, the security label is stored in both the containing directory and Volume Table Of Contents Entry (VTOCE). The security level is set to the level of the containing directory, which must be equal to that of the active process creating the segment (compatibility). The security level must be within the range permissible for the logical volume on which the segment resides (see below). _T_h_e _R_O_O_T _D_i_r_e_c_t_o_r_y The ROOT directory is a container for segments and other objects just as other directories are, except that there is only one ROOT directory and it has no parent. All other directories in the system have the ROOT as the highest directory in their parent chain of directories. The ROOT directory is managed like other directories by the "file system" in ring zero. Its ACL is implicit and is equivalent to status (s) permission to everyone and status-modify-append (sma) permission to the Initializer. The security label of the ROOT is also implicit and is system low. Compatibility is trivial since the ROOT's security level is dominated by all other security levels and the ROOT is the root of the hierarchy H. _D_i_r_e_c_t_o_r_i_e_s Directories are containers for segments and other objects: the building blocks of the hierarchy H. They are managed by the "file system" in ring zero. The ACL is stored in the containing directory, the security label is stored in both the containing directory and VTOCE. Unless specified otherwise, the security level is set to that of the containing directory, which must be equal to that of the process doing the creation; however, the creating process can specify any higher (dominating) security level up to the maximum permitted for the user (compatibility). _M_e_s_s_a_g_e _S_e_g_m_e_n_t_s Message segments are containers for messages. There are three different types of message segments: queue message segments, used primarily as queues for requests to a server process; mailbox message segments, used for mail and interactive messages between users; and user-message message segments, used for communication between the user processes and the Initializer 2 Multics Security Model MDD-002 process. The different types of message segments all implement the same access modes (or a subset for some types of message segments). Message segments are managed by segment control and directory control in ring zero. The message segment software is in ring one. All user access to message segments is mediated by the ring one TCB. The ACL of a message segment is stored in the containing directory, and the security label in the directory and VTOCE. The security level is set to the maximum permitted for the user creating the message segment, and the message segment is allowed to contain messages of any level between that of the containing directory and the message segment itself (compatibility). _M_e_s_s_a_g_e_s Messages are the individual entries in a message segment (or mailbox). They are managed by the message segment software in ring one. They have no explicit ACL's; rather, discretionary control depends only on the author of the message and the ACL on the containing message segment. Each message has an individual security label stored in the message header, and a single message segment may contain messages with many different labels. The security level is set by default to that of the sending process, but can be increased (upgraded) either explicitly by the sending process, or automatically if a higher level process receives the corresponding wakeup at the time the message is sent. The security level of a message can be no lower than that of directory containing the message segment and no higher that the maximun level set when the process is created, hence the compatibility axiom is maintained. _N_o_n_-_s_y_s_t_e_m _I_/_O _D_e_v_i_c_e_s_, _D_i_s_k _a_n_d _T_a_p_e _V_o_l_u_m_e_s These objects are RCP-controlled (Resource Control Package) I/O devices and volumes with no internal structure known to the TCB. They are managed in ring one by RCP. They are recorded in the RCP registries, which are segments managed by RCP in ring one and inaccessible outside of RCP. By default, the ACL permits access only to the original owner of the object. This can be changed by recording the pathname of an owner-specified segment in the registry; the ACL of that segment is used as the ACL for the object. The security label, actually a range, for these objects is stored in the registry entry. Compatibility is maintained by restricting the use of these objects to processes whose security level falls within the range. The object range must fall within the range allowed for the object type as defined in the Resource Type Definition Table, a system table writable only by the Initializer. When an RCP object (resource) is acquired by a user 3 MDD-002 Multics Security Model it receives a security label with equal upper and lower limits, both set to the current level of the acquiring process. For devices (which have no memory of previous activation), this assignment is temporary: when the user releases the device, another user at a different level can acquire it. For volumes, the assignment is permanent: once the volume is written, it retains the label it received until it is explicitly cleared by a security administrator. Thus the transition between active and inactive is controlled. _C_o_m_m_u_n_i_c_a_t_i_o_n _C_h_a_n_n_e_l_s These resources are recorded in the Channel Definition Table (CDT), a system table writable only by the Initializer.SysDaemon process. All management of channels to other processes is performed by the Initializer. The ACL for a channel is kept on a segment of the channel's name in a system directory (>sc1>rcp). The security label, actually a range, is stored in the CDT. As for RCP devices, the range restricts use of the channel to processes whose security level falls within the range. When a channel is assigned to a process, the current security level for the channel is temporarily set to the security level of the requesting process. Unassigned channels have no implications on the security model, they are inactive. The compatibility property is maintained by the trivial nature of the communication channel hierarchy - CDT, channel. _S_y_s_t_e_m _D_i_s_k _V_o_l_u_m_e_s _(_L_o_g_i_c_a_l _V_o_l_u_m_e_s_) Logical volumes are groups of disks usable by the "file system" (page control, segment control, directory control, etc.). They contain individually labeled segments and directories (as opposed to RCP-controlled disks, which have no internal structure known to the TCB). Logical volume registration is managed in ring one by the logical volume and master directory control software. The ACL for a logical volume is kept on a segment whose location is stored in the registration segment. The security label, actually a range, of a logical volume is stored in its registration segment, which is kept in a system directory (>lv) and also in the volume label of each disk in the logical volume. The range restricts the security levels of the segments that are created on that volume. The minimum and maximum values in the range are specified by the system administrator when the volume is initially defined to the system. Compatibility is trivial - registration, volume. Once a volume is created, it remains active, hence inactive volumes are not a concern. 4 Multics Security Model MDD-002 _P_r_o_c_e_s_s_e_s _(_I_n_t_e_r_p_r_o_c_e_s_s _C_o_m_m_u_n_i_c_a_t_i_o_n_) The only operation a process may perform with respect to another process is communication. Interprocess communication (IPC) is mediated in ring zero by traffic control (the process scheduler). Process creation is performed by the Initializer process. Processes have no explicit ACL's; however, for a process to be communicated with it must have first published one of its IPC channel names (a number) in some predetermined location. This provides discretionary control, since the channel name will be unknown unless published and the names are generated in such a way as to be a practical impossibility to calculate. The security label for a process is stored in the Active Process Table Entry (APTE) for the process, as well as in various places in per-process storage. The label is derived at process creation time from the security level ranges stored in the administrative tables defining users (PNT), projects (SAT, PDT), and communications channels (CDT). The security level of the object process must dominate that of the sending process. There are no compatibility implications, and processes are never inactive in the Activity axiom sense. _M_U_L_T_I_C_S _S_U_B_J_E_C_T_S There is only one kind of subject in the Multics system: the Multics Process. _P_r_o_c_e_s_s_e_s The Multics process is the agent of change in the Multics system state. A Process may change the current access set, the hierarchy, and access permissions. Processes may not change the security level of objects other than to make them active or inactive. All changes that a process may make to the system state are constrained to conform to the axioms of compatibility, tranquility, simple security, and *-property and to the axiom of discretionary security. With regard to the activity axiom, objects except for channels and RCP controlled devices cease to exist when made inactive, channels and RCP controlled devices are handled by the controlling subsystems such that this axiom is not violated. Process creation is performed by the Initializer process. The security label for a process is stored in the Active Process Table Entry (APTE) for the process, as well as in various places in per-process storage. The label is derived at process creation time from the security level ranges stored in the administrative tables defining users (PNT), projects (SAT, PDT), and communications channels (CDT). A process has a user ID stored in the APTE which is used to identify the process in discretionary 5 MDD-002 Multics Security Model access control decisions. This user ID taken with the Access Control List (ACL) of an object and applying the matching rules described below allow the system to calculate the access permission the subject process has to the object, i.e., the equivalent of looking up that access attribute for a given subject and object in the Access Matrix M described in the Model. _M_U_L_T_I_C_S _A_C_C_E_S_S _C_O_N_T_R_O_L _- _I_T_S _R_E_L_A_T_I_O_N_S_H_I_P _W_I_T_H _T_H_E _M_O_D_E_L The next section describes the access modes a subject may have with respect to the various object types and the relationship these access modes have with the access modes of the model. A subject's "effective access" to an object is determined by the combination of its Discretionary Access Control (DAC) access to an object and Mandatory Access Control (MAC) access. It represents the set of operations a subject may perform on an object. The system state variable M, the access matrix, of the model corresponds to a distributed set of software structures throughout the Multics TCB. For most objects the information of the access matrix corresponds to the information represented in ACL's, Access Control Lists, stored in the containing directories. Objects that do not exist directly in the file system such as RCP controlled devices and logical volumes, have Access Control Segments (ACS's) associated with them which are ordinary segments created in the file system whose only purpose is to possess an ACL that a TCB subsystem such as RCP may match with a subject. The subject's access to the ACS is used to infer that subject's access to the associated non-file system object. These ACL's taken with their rules of interpretation elaborated below specifically correspond to entire columns of M, that is, the complete list of access modes that all subjects have to a single object. For object processes, the access matrix columns are implicit and access exists for sending IPC wakeups to a process for all subjects that have been previously informed by the object process of a valid IPC channel. For messages, the access matrix column can be computed from the ACL associated with the message segment taken together with the author subject stored in the message itself. All references to objects are mediated through a combination of trusted software and hardware. The system state variable b, the current access set, of the model corresponds to a distributed set of temporary, mostly per process, software structures. For some objects such as messages in message segments, elements of b are not stored but are calculated upon each reference to the object. For segments, the first reference to the segment is mediated by software which computes the subject's effective access to the segment and builds a Segment Descriptor Word (SDW) which is used by hardware to enforce access on subsequent 6 Multics Security Model MDD-002 references to the segment. This effective access is derived from the ACL in combination with the mandatory access relationship determined by the subject's current security level (SL(Si) or fc(Si) as used in the model) compared with the object's security level (fo(Oj)). Software invalidates these SDW's forcing them to be recalculated when a change in the current access set (ACL on the segment) might make the current access granted by the SDW inaccurate. These SDW's are stored in per process TCB data bases in the process directories called the Known Segment Tables, KST's. For directories, message segments, and messages, access is calculated upon each reference by the associated TCB software subsystem. For objects that have Access Control Segments associated with them, access is calculated based on the ACS segment and then stored in TCB data bases associated with the subsystem controlling access and checked upon each reference. Access of subjects to object processes is mediated upon each reference, each IPC wakeup, by TCB software. All references to objects are initiated by processes through calls to the TCB via the TCB interface (subroutine interface) documented in the Descriptive Top-Level Specification (DTLS) or to segment objects through machine instruction memory references. _D_i_s_c_r_e_t_i_o_n_a_r_y _A_c_c_e_s_s _- _A_c_c_e_s_s _C_o_n_t_r_o_l _L_i_s_t _M_a_t_c_h_i_n_g Discretionary access for most objects is determined from the Access Control List (ACL) associated with the object, and the set of modes in the ACL term matching the subject name. An ACL term may specify any combination of access modes for an object. The subject name is the three component user ID associated with each Multics subject - process. The first component of the user ID is the account name, this often corresponds to a given person's name. The second component is the project name, a user is always registered on a least one project. The third component is a process tag which by convention is used to identify different kinds of processes; for example, an interactive user will have a project tag of "a", while an absentee (batch) user will have a tag of "m". A typical user ID would look like: Tague.Multics.a. An ACL for an object is a list of user ID's that may access the object and which Multics access modes, read or write for example, that that subject has to the object. The Multics system implements certain ACL related conventions that make the maintenance of a large computer system with many objects and users feasible. Four conventions are imposed: 1) No access term can appear more than once in any ACL. 7 MDD-002 Multics Security Model 2) There are eight groups of access terms which are arranged in an ACL in the following order: (1) no asterisk component (2) asterisk third component only (3) asterisk second component only (4) asterisk second and third component only (5) asterisk first component only (6) asterisk first and third component only (7) asterisk first and second component only (8) all asterisk components 3) The entry that matches a given subject is the first access term on the ordered ACL that matches the subject user ID. Where matching is component by component and an asterisk ACL term component will match any value of the corresponding user ID component. 4) If no ACL term matches a given subject user ID, that subject has no access or "null" ("n") access to the object. _M_a_n_d_a_t_o_r_y _A_c_c_e_s_s _C_o_n_t_r_o_l _- _S_e_c_u_r_i_t_y _L_a_b_e_l _C_o_m_p_a_r_i_s_o_n Multics supports eight hierarchically ordered sensitivity levels and eighteen categories which together form a partially ordered set of security levels under a dominate function. The security level A is said to dominate security level B (SL(A) >= SL(B)) if the hierarchical classification of A is greater than or equal to that of B and the non-hierarchical categories of A include all those of B as a subset. Security level A is said to equal that of security level B (SL(A) = SL(B)) if level A dominates level B and level B dominates level A (SL(A) = SL(B) if and only if SL(A) >= SL(B) and SL(B) >= SL(A)). Security level A is said to be isolated from security level B if neither level A dominates level B nor level B dominates level A. A subject's maximum security level is the minimum of: 1) the maximum user security level from the Person Name Table (PNT) which contains a maximum and default security level for each user, 2) the maximum project security level from the System Administrator Table (SAT) which contains the maximum security level for each project (users must login to some project), 3) the maximum user security level for the project from the Project Definition Table (PDT) which can impose a maximum security level for a user on a particular project, and 4) the maximum communication channel security level from the Channel Definition Table (CDT). 8 Multics Security Model MDD-002 The current subject security level is equal to the security level specified upon login, or if not given explicitly, the default security level specified in the PNT. The user is not allowed to login if the current subject's security level would be greater than that allowed by the subject's maximum security level (nor is the user allowed to login if the current subject's security level would be lower than the maximum of the minimum levels specified for this user in the SAT, PDT, PNT, and CDT). Once a user's access to login at a specified authorization, security level, has been validated, a process is created for the user and the security level of the subject process is stored in a TCB data base known as the Active Process Table (APT) as well as the per process data base known as the Process Data Segment (PDS). This security level corresponds to the subject's current security level or fc(Si) in the model. The system state variable f, the level function, made up of the three components: fs, maximum subject security level, fo - object security level, and fc - current subject security level is distributed among several TCB data bases in the following way: The maximum subject security level and the current subject security level of a given subject, process, is stored in that process's process directory in the Process Data Segment. For objects whose discretionary access is controlled by ACS segments, their security level is stored in TCB data bases such as RCP registries. For other objects, the security level is stored in the same structure as that object's discretionary access information, e.g., a segment's security level is stored with its ACL in its parent directory. This state information is used with discretionary access information, the access matrix, to compute the effective access that is checked and enforced throughout the Multics TCB as described above. _O_B_J_E_C_T _A_C_C_E_S_S _M_O_D_E_S _- _T_H_E_I_R _C_O_R_R_E_S_P_O_N_D_E_N_C_E _T_O _T_H_E _M_O_D_E_L The following subsections describe the access modes for each type of Multics object. For each Multics access mode, a correspondence to the access modes of the model is made. It is through Multics' enforcement of its access modes with their demonstrated correspondence to the access modes of the model that Multics enforces the Simple Security axiom and the *-property axiom. Each section begins with a statement of mandatory access rules that apply to all objects of this type. 9 MDD-002 Multics Security Model _S_e_g_m_e_n_t _A_c_c_e_s_s _M_o_d_e_s For segments, the mandatory access compatibility rule implies that SL(o) for the segment is always equal to SL(o) for the containing directory. read A process granted read access can execute (r) instructions that cause data to be fetched (read) from the segment. This read access maps directly to read access in the B&L model. A subject is granted read access if the matching ACL entry specifies _r mode and if the subject's security level dominates the segment's security level. SL(s) >= SL(o). write A process granted write access can execute (w) instructions that cause data in the segment to be modified. This write access maps into read and write access in the B&L model. A subject is granted read and write access if the matching ACL entry specifies _w mode and if the subject's security level is equal to the segment's security level. SL(s) = SL(o). execute A process granted execute access can transfer to (e) this segment and cause portions of the segment to be interpreted and executed as instructions. This execute access maps into execute access in the B&L model, though it is necessary to have Multics _r access to execute a program. A subject is granted execute access if the matching ACL entry specifies _e mode and if the subject's security level dominates the segment's security level. SL(s) >= SL(o). null The process cannot access the segment in any way. (n) This null access maps into no B&L model access (null set). A subject is granted no access if the matching ACL entry specifies no access modes or no ACL entry matches or if the subject's security level does not dominate the object's security level. not (SL(s) >= SL(o)). _D_i_r_e_c_t_o_r_y _a_c_c_e_s_s _m_o_d_e_s_: For directories, the mandatory access compatibility rule implies that SL(o) for a directory always dominates SL(o) for the 10 Multics Security Model MDD-002 containing directory. The ROOT directory is a special case, the security level of the ROOT is dominated by all security levels. SL(root) = system low. status A process granted status access can obtain (s) information about the attributes of the directory as well as attributes of segments, directories and links contained in the directory. This status access maps into read access in the B&L model. A subject is granted read access if the matching ACL entry specifies _s mode and if the subject's security level dominates the directory's security level. SL(s) >= SL(o). modify A process granted modify access can modify (m) attributes of the directory as well as attributes of the segments, directories, and links contained in the directory. Components in the directory can also be deleted. With the exception: The bit count attribute is considered part of a segment's contents, and therefore requires _w access to the segment whose bit count is to be changed, rather than _m to the directory. The same is true of the damaged switch. This modify access maps into read and write access in the B&L model. A subject is granted read and write access if the matching ACL entry specifies _m mode and if the subject's security level is equal to the directory's security level. SL(s) = SL(o). append A process granted append access can create new (a) directories, segments, and links in the directory. This append access maps into read and write access in the B&L model. A subject is granted read and write access if the matching ACL entry specifies _a mode and if the subject's security level is equal to the directory's security level. SL(s) = SL(o). null A process with no access to a directory can still (n) reference objects contained in the directory to which it has non-null access, and read the attributes of those objects, but cannot reference any other objects or attributes. This null access maps into the execute mode of access for the B&L model. A subject is granted no access if the matching ACL entry specifies no access modes or no ACL entry matches or if the subject's 11 MDD-002 Multics Security Model security level does not dominate the directory's security level. not (SL(s) >= SL(o)). _M_e_s_s_a_g_e _S_e_g_m_e_n_t _e_x_t_e_n_d_e_d _a_c_c_e_s_s _m_o_d_e_s_: When a message segment is created, it is assigned an SLmax(o) equal to the maximum SL(s) permitted for the creating process (message segments are multilevel objects). The message segment implementation ensures that SLmax(o) for the message segment always dominates SL(o) for any messages placed in the message segment. The mandatory access compatibility rule ensures, as for segments, that SL(s) for any reference to the message segment in any way that SL(s) dominates SL(o) for the containing directory. Therefore, since SL(o) for a message in a message segment is set equal to SL(s) for the subject adding it, SL(o) for all messages in a message segment must dominate SL(o) for the containing directory. In addition to the requirements listed below, for all message segment operations, a process may perform the operation if and only if: SLmax(segment) >= SL(s) and SL(s) >= SL(dir). add A process granted add access to a message segment (a) can add a message. This add access maps into write access in the B&L model. A subject is granted write access if the matching ACL entry specifies _a mode and if the messages' security level dominates that of the subject's. SL(o) >= SL(s). delete A process granted delete access to a message segment (d) can delete any message. This delete access maps into read and write access in the B&L model. A subject is granted read and write access if the matching ACL entry specifies _d mode and if the subject's security level is equal to the message's security level. SL(s) = SL (o). read A process granted read access to a message segment (r) can read any message. This read access maps into read access in the B&L model. A subject is granted read access if the matching ACL entry specifies _r mode and if the subject's security level dominates the message's security level. SL(s) >= SL(o). 12 Multics Security Model MDD-002 own A process granted own access to a message segment (o) can read or delete its own messages. This own access maps into read and write access in the B&L model. A subject is granted read and write access if the matching ACL entry specifies _o mode and if the subject's security level is equal to the message's security level for deletion or if the subject's security level dominates the message's security level for reading. SL(s) = SL(o) for delete, SL(s) >= SL(o) for read. status A process granted status access to a message segment (s) can find out how many messages there are. This status access maps into read access in the B&L model. A subject is granted read access if the matching ACL entry specifies _s mode and if the subject's security level dominates the messages' security level. SL(s) >= SL(o). wakeup A process granted wakeup access to a mailbox type (w) message segment can send an interactive message to the mailbox. This mode is valid only for mailbox message segments. This wakeup access maps into write access in the B&L model. A subject is granted write access if the matching ACL entry specifies _w mode and if the message's security level dominates the subject's security level. SL(o) >= SL(s). urgent A process granted urgent wakeup access to a mailbox (u) type message segment can send an interactive message to the mailbox with an urgent wakeup. This mode is valid only for mailbox message segments. This urgent wakeup access maps into write access in the B&L model. A subject is granted write access if the matching ACL entry specifies _u mode and if the message's security level dominates the subject's security level. SL(o) >= SL(s). null The process cannot access the message segment in any (n) way. This null access maps into no B&L model access. A subject is granted no access if the matching ACL entry specifies no access modes or no ACL entry matches or if the subject's security level is not in the range of the message segment's security level. 13 MDD-002 Multics Security Model _R_C_P _a_c_c_e_s_s _m_o_d_e_s_: The ACL for a device is on the RESOURCE_NAME.acs segment for that device. The ACL for a volume can be found by locating the ACS segment that applies to the volume in the registry RESOURCE_TYPE.rcpr. If no ACS segment is in the registry for a volume, defaults are applied. Free resources known to the system (inactive) have a security level range specified in the registry RESOURCE_NAME.rcpr (minimum security level SLmin(o) and maximum security level SLmax(o)). While active, a resource's security level is set to the subject's security level (SL(s) = SL(o)) as long as the subject's security level is within the objects range, that is, min and max are both set to the subject's level. For all RCP operations, in addition to the requirements listed below, the operation may be performed if and only if: SL(s) >= SLmin(o) and SLmax(o) >= SL(s). read A process granted read access to a resource can read (r) the contents of the resource. This read access maps into read access in the B&L model. A subject is granted read access if the matching ACL entry specifies _r mode and if the subject's security level dominates the resource's max security level. SL(s) >= SL(o). write A process granted write access to a resource can (w) write the contents of the resource. This write access maps into read and write access in the B&L model. A subject is granted read and write access if the matching ACL entry specifies _w mode and if the subject's security level equals the resource's security level. SL(s) = SL(o). executive A process granted executive access to a resource can (e) change the attributes of the resource; in effect, grant the same rights to the resource as the resource owner. This executive access maps into read and write access in the B&L model. A subject is granted read and write access if the matching ACL entry specifies _e mode and if the subject's security level equals the resource's security level. SL(s) = SL(o). null The process cannot access the resource in any way. (n) This null access maps into no B&L model access. A subject is granted no access if the matching ACL entry specifies no access modes or no ACL entry 14 Multics Security Model MDD-002 matches or if the subject's security level is not dominated by the resource's security level. _L_o_g_i_c_a_l _V_o_l_u_m_e _a_c_c_e_s_s _m_o_d_e_s_: Logical volumes have an access range rather than a single access level. read/ A process granted read/write may mount the logical write volume. Both _r and _w must be present in the ACL (rw) term of the segment. The subject's security level must dominate the volume's minimum security level and be dominated by the volume's maximum security level. SL(s) >= SLmin(o) and SLmax(o) >= SL(s). executive A process granted executive access to a logical (e) volume can change the attributes of the logical volume as a volume administrator; in effect, granting the same rights to the resource as the logical volume owner. The subject's security level must equal the minimum security level of the volume. SL(s) = SLmin(o). null The process cannot access the logical volume in any (n) way. This null access maps into no B&L model access. A subject is granted no access if the matching ACL entry on the corresponding ACS segment specifies no access modes or no ACL entry matches. _C_o_m_m_u_n_i_c_a_t_i_o_n _C_h_a_n_n_e_l _a_c_c_e_s_s _m_o_d_e_s Each communication channel is assigned a minimum SLmin(o) and maximum SLmax(o) security level, in addition to the current security level SL(o) it receives while in use. read/ A process granted read/write access may attach the write channel and transmit data across it. Both read and (rw) write must be present in the ACL term of the ACS segment. The subject's security level must dominate the minimum security level of the object as well as be dominated by the maximum security level of the object. SL(s) >= SLmin(o) and SLmax(o) >= SL(s). null The process cannot access the channel in any way. (n) This null access maps into no B&L model access. A subject is granted no access if the matching ACL entry on the corresponding ACS segment specifies no access modes or no ACL entry matches. 15 MDD-002 Multics Security Model _P_r_o_c_e_s_s _a_c_c_e_s_s _m_o_d_e_s Processes are treated as objects for interprocess communication. Each process is assigned a security level, SL(s) for the sending process and SL(o) for the receiving process. There is no explicit discretionary control for process objects. send A process with "send wakeup" access to another wakeup process may send a wakeup and a 72-bit data message (w) to that process. The subject's (sending process') security level must by dominated by that of the object (receiving process). SL(o) >= S(s). null The process cannot send a wakeup to the other (n) process. The process cannot access the channel in any way. This null access maps into no B&L model access. A subject is granted no access if the object's security level does not dominate the subject's. _D_I_R_E_C_T_O_R_Y _V_I_S_I_B_I_L_I_T_Y _A_N_D _T_H_E _C_O_M_P_A_T_I_B_I_L_I_T_Y _A_X_I_O_M In Multics, directories are used to implement the file system hierarchy. Most objects are contained in directories, including other directories, and thus the full name of an object is the object name itself concatenated with the names of all the containing directories. Because null access to directories maps into the "execute" mode of the model, a subject may exercise access rights to an object regardless of the access rights to containing directories. Thus, it is possible for a subject to sense, indirectly, the existence of intermediate directories within the name of an object, even if the directories are otherwise inaccessible, because the object itself is accessible. The "compatibility" restriction on directories requires that a directory contain non-directory objects only at the same level as the directory, and directory objects at that level or above. Consequently, if the directory is at a security level inaccessible to the subject, all objects contained in the directory, or in other directories contained in the directory, are guaranteed also to be inaccessible, and therefore there is no way to infer the existence of a directory that is inaccessible due to the mandatory security policy. ----------------------------------------------------------- Historical Background This edition of the Multics software materials and documentation is provided and donated to Massachusetts Institute of Technology by Group BULL including BULL HN Information Systems Inc. as a contribution to computer science knowledge. This donation is made also to give evidence of the common contributions of Massachusetts Institute of Technology, Bell Laboratories, General Electric, Honeywell Information Systems Inc., Honeywell BULL Inc., Groupe BULL and BULL HN Information Systems Inc. to the development of this operating system. Multics development was initiated by Massachusetts Institute of Technology Project MAC (1963-1970), renamed the MIT Laboratory for Computer Science and Artificial Intelligence in the mid 1970s, under the leadership of Professor Fernando Jose Corbato. Users consider that Multics provided the best software architecture for managing computer hardware properly and for executing programs. Many subsequent operating systems incorporated Multics principles. Multics was distributed in 1975 to 2000 by Group Bull in Europe , and in the U.S. by Bull HN Information Systems Inc., as successor in interest by change in name only to Honeywell Bull Inc. and Honeywell Information Systems Inc. . ----------------------------------------------------------- Permission to use, copy, modify, and distribute these programs and their documentation for any purpose and without fee is hereby granted,provided that the below copyright notice and historical background appear in all copies and that both the copyright notice and historical background and this permission notice appear in supporting documentation, and that the names of MIT, HIS, BULL or BULL HN not be used in advertising or publicity pertaining to distribution of the programs without specific prior written permission. Copyright 1972 by Massachusetts Institute of Technology and Honeywell Information Systems Inc. Copyright 2006 by BULL HN Information Systems Inc. Copyright 2006 by Bull SAS All Rights Reserved