MULTICS DESIGN DOCUMENT MDD-013 To: MDD Distribution From: Michael A. Pandolf Date: June 1, 1985 Subject: Multics Message Segment Facility Abstract: Description and documentation of the internal and user interfaces of the Multics Message Segment Facility. Revisions: REVISION DATE AUTHOR initial 85-06-01 Michael A. Pandolf _________________________________________________________________ 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-013 Multics Message Segment Facility CONTENTS Page Section 1 Introduction to Message Segments . . . . 1-1 1.1 Purpose of Message Segments . . . 1-1 1.2 Requirements . . . . . . . . . . . 1-1 1.3 Design Goals . . . . . . . . . . . 1-2 1.4 Design . . . . . . . . . . . . . . 1-2 1.4.1 Access Considerations . . . . 1-2 1.4.2 Consistency of Contents . . . 1-3 1.4.3 Issues Regarding the Read Operation . . . . . . . . . . . . 1-4 1.5 Overall Structure . . . . . . . . 1-4 1.5.1 User Ring Interfaces . . . . 1-4 1.5.2 Ring One's Top Layer . . . . 1-5 1.5.3 The Message Segment Primitives . . . . . . . . . . . . 1-5 Section 2 The Message Segment Security Model . . . 2-1 2.1 General Issues . . . . . . . . . . 2-1 2.2 Discretionary Access Control . . . 2-1 2.3 Mandatory Access Control . . . . . 2-3 2.3.1 Access Class Characteristics of Message Segments . . . . . . . 2-3 2.3.2 Enforcement of Mandatory Access Control . . . . . . . . . . 2-3 2.4 Access Auditing . . . . . . . . . 2-4 Section 3 User Ring Interfaces . . . . . . . . . . 3-1 Section 4 The Gate Target and Access Kernel . . . . 4-1 Section 5 Message Segment Primitives . . . . . . . 5-1 Section 6 Ancilliary Services . . . . . . . . . . . 6-1 ii Multics Message Segment Facility MDD-013 SECTION 1 INTRODUCTION TO MESSAGE SEGMENTS _1_._1 _P_U_R_P_O_S_E _O_F _M_E_S_S_A_G_E _S_E_G_M_E_N_T_S The Message Segment Facility provides tools for the Multics programmer to create, delete, and manipulate containers for arbitrary messages. It controls the existence, attributes, and contents of these containers. _1_._2 _R_E_Q_U_I_R_E_M_E_N_T_S The requirements of the Message Segment Facility are threefold. First, it must have an interface to provide a queue facility for the I/O and Absentee daemons. This queue facility must perform the following operations: ox Enter a request so that its order is retained in the queue. ox Obtain a request in some ordered fashion from the queue. ox Delete a request from the queue. ox Rewrite the request within the same queue. ox Obtain status about the queue. ox Provide access control that allows users of the facility to enter, obtain, and cancel their own requests without being able to tamper with the requests of other users. There must be a second interface into the Facility to support mail subsystems within Multics. This interface must provide the tools to: ox Add, read, and delete messages in an ordered fashion. ox Send, obtain, and delete one's own messages without affecting messages sent by other users. 1-1 MDD-013 Multics Message Segment Facility ox Allow a process to accept and defer the notification of the receipt of a message. The last requirement is for the Facility to allow the programmer to design other types of message segments using the interfaces provided here as a basis for their implementation. For example, the Answering Service uses mseg_ for its user_message_ facility, which allows privileged processes to communicate with user processes. _1_._3 _D_E_S_I_G_N _G_O_A_L_S In order to fulfill the above requirements, the Message Segment Facility is designed to: ox Provide for the protected and ordered exchange of messages between processes and within a process. ox Be able to restore its message data to a consistent form so that it continues functioning if a message is damaged. ox Minimize the time during which any primitive operation puts the message data in an inconsistent state, to minimize the chance that it will be left in this state by crash or malfunction. ox Provide a well-defined interface to facilitate its use by higher level subsystems. ox Be executable in the user ring for debugging purposes. _1_._4 _D_E_S_I_G_N _1_._4_._1 _A_c_c_e_s_s _C_o_n_s_i_d_e_r_a_t_i_o_n_s The container used by the Message Segment Facility is a special segment called a "message segment". A message segment is directly accessible only from the administrative ring (ring one) and therefore must have ring brackets of [1, 1, 1]. In addition, certain types of message segments have suffix requirements. A queue message segment, one handled through the message_segment_ gate, must have the suffix "ms". A mailbox type message segment, one handled through the mailbox_ gate, must have the suffix "mbx". Message segments used by the user_message_ facility have no required suffix. Discretionary access modes to the message segment are interpreted at two levels. The first level, known as "raw access" (and encoded into hardware useable form) is set to 1-2 Multics Message Segment Facility MDD-013 read/write for all processes. That is, any potential user of the container must be able to read and write its contents. The second level of access control, known as "extended access", is interpreted by the Facility software. These modes define the actions that the inner ring software is allowed to perform on behalf of its outer ring caller. Therefore, it is the extended access that controls how a message segment is referenced. Relative to the Multics Access Isolation Mechanism, message segments also behave in an extended manner. Instead of existing at a single access classification, they are considered to be multi-class objects. The lower bound of a message segment's access class is defined by the access class of its parent directory; the upper bound by the access class associated with the segment itself. This permits it to contain messages of varying access classes, something not possible if AIM were to be enforced in its simplest interpretation. In this model, it is the message that exists at a specific access class and is treated in the conventional AIM manner. _1_._4_._2 _C_o_n_s_i_s_t_e_n_c_y _o_f _C_o_n_t_e_n_t_s The internal consistency of a message segment is protected as follows: ox All operations involving the segment's contents (reading and writing) are done under a lock. ox All IPS signals, including quits, are masked by default when in the inner ring. This is not done by mseg_ itself but by the gate crossing. Because signals should not be masked for a long period of time, mseg_ runs with guaranteed eligibility on so that it can complete its job quickly and return. ox The Facility contains a salvager that can find messages in a damaged segment and reconstruct the chronological chain, though not the text contents, of the messages. This salvager is invoked in a variety of circumstances, including: 1) when the modification_in_progress bit, turned on temporarily during the sequence of operations that put the segment in an inconsistent state, is found to have been left on; 2) when the salvage_in_progress bit is found to have been left on, indicating that a previous salvage was interrupted; 3) at the time of a crawlout from the inner ring, including record-quota overflow; 4) when certain kinds of inconsistencies are detected in the header information or message chain; 5) when the segment's damaged switch is found to be on. 1-3 MDD-013 Multics Message Segment Facility _1_._4_._3 _I_s_s_u_e_s _R_e_g_a_r_d_i_n_g _t_h_e _R_e_a_d _O_p_e_r_a_t_i_o_n The following gate calls are provided for reading messages: ox Read the first message. ox Read the last message. ox Read the message specified by a unique message identifier. ox Read the message immediately after a specified one. ox Read the message immediately before a specified one. The caller thus has the ability, by combining calls, to find any desired message. The chasing of message threads is performed in the inner ring, and beyond control of the caller. A caller that has access to read only his own messages ("o" but not "r" extended access) must use a separate set of entry points for reading own messages. All read entry points treat messages that are inaccessible to the caller because of MAC restrictions as if they are not there. The read-first operation returns the first message that the caller has access to, or a no-message error code if there are no messages that the caller has access to. The read-next operation returns the next message that the caller has access to, and so on. There is no way for the caller to find out about the existence of inaccessible messages. _1_._5 _O_V_E_R_A_L_L _S_T_R_U_C_T_U_R_E _1_._5_._1 _U_s_e_r _R_i_n_g _I_n_t_e_r_f_a_c_e_s The user ring interface to the Message Segment Facility is comprised of two components. First is the Extended Entry Type suffix layer. The two modules at this layer, suffix_mbx_ and suffix_ms_, serve to define two file system entry types known as mailboxes and message segments. These modules are called by fs_util_, usually from within a Multics command such as set_acl, and are used to implement a type-independent command level environment. The other modules available from the user ring are the gates into ring one: mailbox_, message_segment_, queue_admin_, user_message_, and other type-specific gates. They provide access to those portions of the ring one Message Segment Facility that operate on mailboxes, queues, Answering Service message segments, and other types of message segments. 1-4 Multics Message Segment Facility MDD-013 _1_._5_._2 _R_i_n_g _O_n_e_'_s _T_o_p _L_a_y_e_r The top layer of the Facility in ring one consists of mseg_mbx_ms_gate_target_ and other application-specific gate targets. This layer validates the ring brackets and suffixes of various types of message segment and validates the user's access to the segment. _1_._5_._3 _T_h_e _M_e_s_s_a_g_e _S_e_g_m_e_n_t _P_r_i_m_i_t_i_v_e_s The mseg_ transfer vector references mseg_fs_interface_, mseg_index_, mseg_segment_, mseg_message_, and mseg_utils_. The first module, mseg_fs_interface_, serves as the interface between message segments and the primitive file system. This module creates and deletes message segments and handles ACL's and segment name changes by calling entry points in hcs_. The module mseg_index_ opens and closes message segments, assigning an index to each message segment while it is open. The module mseg_segment_ performs certain operations on the message segment as a whole that are not provided by ring zero: for example, compacting a message segment. Finally, mseg_message_ handles adding, reading, updating, counting, and deleting messages. The module mseg_utils_ provides general utilities for use by the other four modules. 1-5 Multics Message Segment Facility MDD-013 SECTION 2 THE MESSAGE SEGMENT SECURITY MODEL _2_._1 _G_E_N_E_R_A_L _I_S_S_U_E_S Given that the unit of hardware access control in Multics is the segment and that the level of granularity required at times by message segments is the individual message, the Facility must include a layer of software that implements access control at the finer resolution, that of a message. Furthermore, access modes of read and write are not specific enough to define the access rules of all the actions that the Facility provides. The resulting discretionary access control (DAC) mechanism created for message segments defines seven modes to be enforced at the segment level. The mandatory access control (MAC) mechanism has as its objects both message segments and messages. Both DAC and MAC are enforced by code in the Facility. The hardware (and standard) access modes for a message segment must be rw for all of its users. Write access is required even to read a message, because of the need to read and write locks in the message segment. Clearly, another mechanism must be used to aid in enforcement of the access control. Setting the ring brackets to [1,!1,!1] for a message segment provides the required protection. Enforced by hardware, a process must be executing in ring one to either read or write any portion of a message segment, or to modify any of the segment's characteristics. The installed Message Segment software normally runs in ring one. If a process attempts to run the software in an outer ring (for example, during a test), the inner ring message segments are still protected. The Facility software performs all access checking relative to message segments while executing in ring one. _2_._2 _D_I_S_C_R_E_T_I_O_N_A_R_Y _A_C_C_E_S_S _C_O_N_T_R_O_L The Multics supervisor provides the tools necessary for an application to define its own DAC environment. In addition to the standard access modes of read, execute, and write, there is a string of thirty-six bits whose meaning is interpreted by the 2-1 MDD-013 Multics Message Segment Facility Facility for additional access control. This string represents the "extended access" modes. Extended access is not interpreted by ring zero. Mailbox and queue access (both DAC and MAC) is enforced by the module mseg_check_access_. Access is not checked at the mseg_ level. There are seven extended access modes defined for message segments. These modes control access to the message segment itself; therefore, a user tends to have access to all or none of the messages in a message segment, with one exception ("own" access). Note that this does not take into consideration the effects of MAC. The defined modes are: ox add!(a)!!allows a user to add a new message to a message segment. ox delete!(d)!!allows a user to delete or update any message, accept wakeups in the case of a mailbox, and reset the has-been-salvaged bit of a message segment. ox read!(r)!!!!allows a user to read any message in a message segment. ox own!(o)!!!!!allows a user to read or delete any message that he placed in the message segment. For anonymous users, the project identifier must be the same as that of the message sender. For all other users, the person identifier must be the same and the project identifier is irrelevant. ox status!(s)!!allows a user to obtain the value of the salvaged bit or obtain the message count of a message segment. ox wakeup!(w)!!allows a user to send a normal priority wakeup to the process accepting them through the message segment. In this case, the message segment must be a mailbox. ox urgent!(u)!!allows a user to send an urgent priority wakeup to the process accepting them through the message segment. As with wakeup access, the message segment must be a mailbox. Urgent access is not currently used by any applications. Queue message segments do not support the wakeup or urgent modes, since wakeups are not sent through them to a target process. The default extended modes for a mailbox are "adrosw" for its creator, "aow" for SysDaemons, and "aow" for any other user. The default extended modes for a queue message segment are "adros" for its creator and "ao" for SysDaemons. 2-2 Multics Message Segment Facility MDD-013 Upon entering the ring one message segment environment, access to the message segment is checked against the access required for the requested operation. If the caller has appropriate access, processing of the request continues; otherwise, an error code is returned to indicate the failure. A special case exists in the use of the "own" access mode. If a user does not have read access to a message segment, he can still read any message he has added. Entry points whose names begin with the string "own" honor "own" extended modes and are limited to reading only messages added by the user. The delete operation succeeds on a message if the message is accessible according to MAC and either: 1) the caller has "delete" extended access to the message segment, or 2) the caller has "own" extended access to the message segment and the message belongs to the caller. _2_._3 _M_A_N_D_A_T_O_R_Y _A_C_C_E_S_S _C_O_N_T_R_O_L _2_._3_._1 _A_c_c_e_s_s _C_l_a_s_s _C_h_a_r_a_c_t_e_r_i_s_t_i_c_s _o_f _M_e_s_s_a_g_e _S_e_g_m_e_n_t_s Unlike other objects in the Multics hierarchy, a message segment has two access classes associated with it that define a range of minimum and maximum classes. The minimum class is equal to that of the parent directory. The maximum is the message segment's ring zero recognized access class value. The range serves to define the set of messages that can be stored in the message segment: all messages must be dominated by the maximum access class of the message segment and must dominate the minimum (or parent's) access class. Message segments are multi-class because, if they were single-class, a single I/O daemon queue would require up to 2**18 * 2**3 message segments. _2_._3_._2 _E_n_f_o_r_c_e_m_e_n_t _o_f _M_a_n_d_a_t_o_r_y _A_c_c_e_s_s _C_o_n_t_r_o_l MAC as enforced at the message segment level is concerned with operations specific to a message segment, as opposed to more general file system operations such as setting access. When creating, the authorization of the process must equal the access class of the containing directory and the message segment is given as its maximum access class the maximum authorization of the creating process. When copying, the authorization of the process must equal the access class of both the source and target parent directories and the max authorization must dominate the access class of the source segment. A process can open a message segment only if its authorization is within the segment's access class range. 2-3 MDD-013 Multics Message Segment Facility MAC as enforced at the message level is concerned with the ability to add, read, modify, and delete a message. The required access relationships are summarized as follows: ox add!!!!The authorization of the process must be dominated by the access class of the new message, which in turn must be dominated by the process' max authorization. Additionally, the access class of the message must fall within the range of the message segment into which it is added. ox read!!!The authorization of the process must dominate the access class of the message to be read. ox update!The authorization of the process must equal the access class of the message to be updated. ox delete!The authorization of the process must equal the access class of the message to be deleted. MAC for message segments themselves is enforced upon entering the ring one portion of the Facility. Enforcement of access to individual messages is performed as the message chain is being chased in the message segment primitives. A message that cannot be accessed because of its access class is simply treated as if it did not exist. For example, it does not appear in message counts. The gate entry point system_privilege_$ring1_priv_on turns on a mode called "ring 1 privilege". This mode disables all MAC checking of messages and allows a message segment to be opened regardless of its access class range. _2_._4 _A_C_C_E_S_S _A_U_D_I_T_I_N_G The module that checks access (for mailboxes and queues, this is mseg_check_access_) is also responsible for auditing instances of failed access to message segments. For an operation on an entire message segment, the appropriate module checks access and audits the result. For an operation on an individual message, DAC is checked upon entry to the module and MAC is checked when the message is located. In the case of read operations, the read primitive skips inaccessible messages without causing an audit entry for each skipped message. Note that a message can be inaccessible for a combination of MAC and ownership reasons. If no accessible message is found due to MAC reasons, the read entry point audits error_table_$ai_restricted and returns either error_table_$ai_restricted or error_table_$no_message (depending on the operation) to its caller. 2-4 Multics Message Segment Facility MDD-013 Because the module mseg_mbx_ms_gate_target_ calls admin_gate_$admin_level_no_fs_audit to disable file system auditing at the start of every operation, the only audit4 messages that appear during the operation are those issued by mseg_check_access_. 2-5 Multics Message Segment Facility MDD-013 SECTION 3 USER RING INTERFACES 3-1 Multics Message Segment Facility MDD-013 SECTION 4 THE GATE TARGET AND ACCESS KERNEL 4-1 Multics Message Segment Facility MDD-013 SECTION 5 MESSAGE SEGMENT PRIMITIVES 5-1 Multics Message Segment Facility MDD-013 SECTION 6 ANCILLIARY SERVICES ----------------------------------------------------------- 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