MULTICS DESIGN DOCUMENT MDD-010-01 To: MDD Distribution From: Eric J. Swenson Jim Lippard Date: January 1, 1986 Subject: System/User Control Abstract: The management and internal description of the system/user control subsystem on Multics. Revisions: REVISION DATE AUTHOR initial 85-06-01 Eric J. Swenson 1 86-01-01 Jim Lippard _________________________________________________________________ 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-010-01 System/User Control CONTENTS Page Section 1 Overview of the System/User Control Subsystem . . . . . . . . . . . . . . . 1-1 1.1 Definition of Terms . . . . . . . 1-1 1.2 Services of System/User Control . 1-2 1.2.1 Services of System Control . 1-2 1.2.2 Services of User Control . . 1-4 Section 2 Security Issues in System/User Control . 2-1 2.3 Security Issues in System Control 2-1 2.3.1 Control of Operator Input . . 2-1 2.3.2 Control of Operator Use Of Admin Mode . . . . . . . . . . . . 2-3 2.3.3 Control of Operator Access to Daemon Processes . . . . . . . . . 2-3 2.3.4 Message Coordinator (MC) Restrictions . . . . . . . . . . . 2-5 2.3.5 AS Request Service . . . . . 2-6 AS Request: Send_Admin_Command 2-7 AS Request: Send_Daemon_Command 2-7 2.4 Security Issues in User Control . 2-8 2.4.1 Identification and Authentication (I&A) . . . . . . . 2-8 Interactive User I&A . . . . . . 2-8 Password Manipulation . . . . 2-9 Password Management Policy . 2-10 Incorrect Passwords . . . . . 2-10 Physical Security Breaches . 2-10 Project Id Validation . . . . 2-11 Communications Channel Access 2-11 AIM Authorization Checks and Audit Flags . . . . . . . . 2-11 Initial Login Ring . . . . . 2-12 Connecting to Disconnected Processes . . . . . . . . . 2-12 Anonymous Interactive User I&A . . . . . . . . . . . . 2-12 Interactive 'dial' service I&A . . . . . . . . . . . . 2-13 Interactive 'slave' Service I&A . . . . . . . . . . . . 2-14 ii System/User Control MDD-010-01 CONTENTS (cont) Page Interactive 'ftp' Service I&A 2-14 Daemon User I&A . . . . . . . . 2-14 Absentee User I&A . . . . . . . 2-15 2.4.2 Process Creation . . . . . . 2-15 2.4.3 Process Destruction . . . . . 2-16 2.4.4 AS Requests . . . . . . . . . 2-18 AS Request: Dial Service . . . 2-18 Begin Dial Service . . . . . 2-18 Stop Dial Service . . . . . . 2-19 Release Dial Id . . . . . . . 2-19 Attach Channel . . . . . . . 2-19 Release Channel . . . . . . . 2-20 AS Request: Dial-Out Service . 2-20 Dial-Out Channel . . . . . . 2-20 Terminate Dial-Out Channel . 2-21 AS Request: Fatal Process Error Handling . . . . . . . . . . . 2-21 AS Request: Process Termination Monitor . . . . . . . . . . . . 2-21 AS Request: Bump User . . . . . 2-21 AS Request: Note PNT Change . . 2-22 AS Request: Communications Channel Info . . . . . . . . . 2-22 2.4.5 Absentee Facility . . . . . . 2-22 2.4.6 Administrative Table Installation . . . . . . . . . . . 2-23 iii System/User Control MDD-010-01 SECTION 1 OVERVIEW OF THE SYSTEM/USER CONTROL SUBSYSTEM The system/user control subsystem oversees and manages the operation of the system once it is initialized until it is shut down. After Ring-0 and ring-1 initialization is complete, control is passed to the Initializer's Ring-4 process overseer_, system_control_. This module initializes the environment which controls the overall operation of a Multics bootload until it is shut down. Once the "answering service" has been initialized, the user control subsystem manages user processes and provides user services for the duration of the bootload in tandem and close cooperation with the system control subsystem. 111...111 DDDEEEFFFIIINNNIIITTTIIIOOONNN OOOFFF TTTEEERRRMMMSSS The terms by which components of system/user control have been referred are perhaps not the most straightforward and consistent ones. This is due to the fact that the software was designed many years ago and has been continually added to in such a manner as to confuse the definition of the functional components of the subsystem. In particular, the term "Answering Service" has been associated with a nebulous collection of modules, some of which have nothing to do with the original intent of the answering service -- that of answering the "phone lines". In this paper, the term "answering service" will be used sparingly and loosely. It refers to the software which is placed into action with the operator command "startup" (or "multics" followed by a "go" command) and is usually used synonymously with the term "user control". However, strictly speaking, the answering service is only that subset of user control which deals with interactive users coming over communications channels, which listens for channel dialups and provides the initial login dialog. In general, "system control" refers to the operator interface and the support of operator commands which have global system effects, rather than effects aimed at user processes. "User control" refers to the software which performs the identification and authentication (I&A) of users, creates and destroys processes, maintains the several databases used by the 1-1 MDD-010-01 System/User Control "accounting subsystem", provides various services for logged in users, and otherwise manages user and system processes. 111...222 SSSEEERRRVVVIIICCCEEESSS OOOFFF SSSYYYSSSTTTEEEMMM///UUUSSSEEERRR CCCOOONNNTTTRRROOOLLL The following two subsections outline, and briefly describe, the services provided by system and user control. It should be noted that while some services are easily classified as "system control" services, others hover around the fine line between system and user control. For the purpose of this document, the exact categorization of services does not really matter, since both are discussed here. The "answering service" is usually considered a subsystem within user control. However, strictly speaking, some of its functions, for example management of communications channels and multiplexers, are not "user control" functions, but are overall system functions. For this reason, the answering service is not discussed as a subsystem by itself; its functions are divided between the categories of system and user control. 111...222...111 SSSeeerrrvvviiiccceeesss ooofff SSSyyysssttteeemmm CCCooonnntttrrrooolll ox Bootload Console I/O: The bootload console is actually managed by the hardcore supervisor. However, once system control is initialized, input from the console is processed by system control as operator commands. This remains the case until Multics is shut down (or crashes) and BCE is reentered. In the absence of message coordinator terminals, system and user control output is directed to the bootload console as well as to system logs. In addition, before the answering service is started, a necessary requirement for the functioning of the message coordinator, the bootload console remains the sole means of communicating with the system. ox Message Coordinator: System control provides for the establishment of one or more terminals from which operator input may be solicited and output from various daemon processes and system/user control is directed. These terminals may be dynamically added and removed. System messages may be dynamically routed and rerouted to any of the message coordinator terminals and the bootload console. ox Operator Command Processing: System control responds to operator input on the bootload console or from message coordinator terminals and processes this input as operator commands. Output generated from the request is routed to the terminal initiating the request. 1-2 System/User Control MDD-010-01 Before input will be processed, however, system control may require the operator to log in with the sign_on request (see "Identification and Authenticaion (I&A) of Operators", below). ox Identification and Authentication (I&A) of Operators: A system administrator may configure the system in such a way that an operator is required to log in (with the sign_on request) before he is allowed to execute operator commands. System control prompts for and validates a userid and password, and ensures the specified user is registered as an operator. It logs successful and unsuccessful attempts to log in. An optional "inactivity timeout" may be set which causes an operator terminal (message coordinator terminal or bootload console) to be logged out if no commands have been issued at the terminal for a specified time. An operator is automatically logged out if a message coordinator terminal hangs up. Explicit operator logout is requested with the "sign_off" request. ox Logging in System Control and Admin Logs: System and User control share a log in which messages from the various subsystem are placed. This log is commonly, but perhaps inappropriately, referred to as the "answering service log" although its clients extend beyond this body of software. In particular, system messages which originate before the answering service is started are directed to this log as well as the bootload console. The system control log (>sc1>as_logs>log) records interesting events which occur within the system/user control process. The "admin" log (>sc1>as_logs>admin_log) contains a record of operator commands and system responses to these commands. It also records commands executed in admin mode and send_admin_command lines and their associated responses. ox Initiation and Shutdown of Answering Service Sessions: Users are not able to log in until the answering service is initialized. System control commands control the starting and stopping of the answering service and accounting software. ox Special "admin mode" Listener for Maintenance Purposes: In special cases, it may be necessary to execute normal Multics commands in the Initializer process. "Admin" mode provides this capability and its use is controlled by an optional password. All input entered while in admin mode is audited in the admin log. ox Physical Device and Logical Volume Control Functions: The state of hardware modules (CPUs, SCUs, IOMs, MPCs, FNPs, etc.) and physical devices (tape drives, disk drives, 1-3 MDD-010-01 System/User Control printers, etc.) may be dynamically manipulated via system control in response to operator commands. In addition, storage system logical volumes may be mounted or demounted. ox Control of Communications Channels and Multiplexers: Hardware and software communications channel multiplexers (FNPs, x25, etc.) may be controlled via operator commands. Multiplexers may be loaded, dumped, started, stopped, and shutdown. Individual communications channels may be added and deleted as well. ox User Requests to Issue "admin" or "daemon" Commands: Arbitrary command lines may be executed in the Initializer (system control) process, and system daemons may be manipulated by making requests to the "answering service request subsystem." Access checking is performed in order to prevent unauthorized users from utilizing this facility. ox Process Environment and Error Handling for the Initializer Process: The overall process environment in which the Initializer process and its associated subsystems run is established and maintained by system control. In particular, the graceful handling of unexpected errors is the responsibility of system control. ox Miscellaneous Functions: Various other commands which do not fall into any of the above system control categories may be executed by operators. These include the general "exec" command interface, which allows sites to extend the operator command repertoire to include site-tailored functions. In addition, there are commands to add messages to the system control log and change the system version id. 111...222...222 SSSeeerrrvvviiiccceeesss ooofff UUUssseeerrr CCCooonnntttrrrooolll ox Identification and Authentication (I&A) For All Users: All logins, whether interactive, absentee, or daemon are identified and authenticated by user control. Interactive logins usually require passwords, while absentee and daemon logins do not. User control ensures a given userid is registered in the Person Name Table (PNT) and that his supplied password matches that stored in the PNT, if any. It also enforces various AIM restrictions and ensures various other checks are passed. Successful and unsuccessful identification and authentications are logged in the system log. ox Management of Interactive Users: The reading of preaccess commands from login channels, 1-4 System/User Control MDD-010-01 including the "login" command and its arguments, is performed by user control. After a user undergoes a successful I&A, he may create a new process, destroy an old one, or connect to a disconnected one. Once an interactive user is connected to a process, a terminal hangup signal may cause the process to become disconnected, in which case it is suspended (not allowed to run) until reconnected to. ox Management of Daemon Users: In response to operator commands to manipulate daemons, user control will log in or logout daemon processes. Daemons are those processes which run without terminals but communicate with the operator through the message coordinator. Daemons undergo I&A before user control allows them to log in. ox Management of Absentee Users: Requests from users to manipulate absentee processes are handled by the absentee user manager. This software handles | the absentee command AS (Answering Service) request to login | and cancel absentee requests for users. The requests | themselves are stored in Ring-1 message segment queues and processed by the absentee user manager in response to wakeups. | It also handles an event channel over which requests from | the operator to login, cancel, and suspend absentees are | sent. | Absentee processes undergo similar I&A to that of daemon processes. ox Process Creation and Destruction: The interactive, absentee, and daemon user managers all call upon common user control programs to create and destroy processes. Cleanup action may be taken in response to process destruction to, say, detach any attached communications channels, or free up resources owned by the process. ox User Process Terminations Requests: Each of the individual user manager subsystems maintains a per-process event channel over which process terminations are signalled. Logged in users may request logouts or new processes or signal user control of fatal process errors over this channel. The hardcore supervisor notifies user control of terminal hangups and process terminations, and user control may signal itself in order to perform such actions as to "bump" a user or forceably detach a user's terminal. ox System Administrative Table Installations: Requests by system and project administrators to install new copies of system tables are handled in response to wakeups over a system-wide event channel. After validating the 1-5 MDD-010-01 System/User Control right to install tables, user-supplied copies are merged with the active, system copies. Examples of these tables include the System Administrator Table (SAT), Project Definition Tables (PDTs), Channel Definition Table (CDT), and others. ox Accounting and Load Control Subsystem: Before processes are created, and after processes are destroyed, the accounting and load control subsystems are activated in order to perform per-user and per-project accounting and make the necessary adjustments to system load control tables. Processes may be bumped when the system load becomes too high or when they have been inactive for too long. At regular intervals, the accounting software is run in order to record usage information for logged in processes. ox Communications Channel Access Control: Requests to attach and detach communications channels, for autocall, slave, and test-and-diagnotics use are handled by the "answering service request subsystem." Various access control checks are made in order to validate a user's right to access communications channels. ox Miscellaneous Answering Service Requests: In addition to the two types of answering service requests, discussed under "Services of System Control", there are various miscellaneous requests which fall more closely under the category of user control requests. These include requests to be notified of all process terminations, to modify action taken when a user's process is terminated, to bump other users, etc. ox Operator Control of User Processes: Various operator commands are available to bump, unbump, terminate, detach, disconnect, and warn user processes. Other commands allow manipulation of absentee processes. Additionally, operators may manipulate load control parameters, and determine the state of various user control parameters. 1-6 System/User Control MDD-010-01 SECTION 2 SECURITY ISSUES IN SYSTEM/USER CONTROL Because system and user control provide a wide variety of services, these two subsystems implement several independent security policies. Each interface which implements a security policy will be described in detail below. 222...333 SSSEEECCCUUURRRIIITTTYYY IIISSSSSSUUUEEESSS IIINNN SSSYYYSSSTTTEEEMMM CCCOOONNNTTTRRROOOLLL 222...333...111 CCCooonnntttrrrooolll ooofff OOOpppeeerrraaatttooorrr IIInnnpppuuuttt Operator requests may be issued from either the bootload console or any defined message coordinator terminal. For the purpose of this discussion, the term "operator terminal" will apply to either of these sources. The system may be configured to require an operator terminal to be "logged in" before requests are accepted from this terminal. Whether this requirement is enforced is dependent on the setting of the installation parameter, "require_operator_login". If not enabled, no operator login is required for the execution of any operator requests. If enabled, however, system control may require operator login before a operator request is executed. Whether a particular operator request requires login is specified in the table of valid operator requests, sc_request_table_.alm. The per-request flag, "no_login_needed", if specified, indicates no login is required for the request. This feature is necessary, for example, to prevent recursion when executing the "sign_on" request, used to log in. Additionally, the "." request, does not require login as it is used to display the name of the terminal logged-in operator, if any. Further, sites may wish to configure other requests to not require login. Operator login is either initiated automatically when a request is issued on a not-logged-in terminal, or on demand, in response to a "sign_on" request. The operator supplies a userid and a 2-1 MDD-010-01 System/User Control password which is validated in much the same way as for normal user login. That is, the userid must be registered in the Person Name Table (PNT) and the specified password must match the encrypted password stored in the PNT. The "operator" flag must be enabled in the PNT entry for the user. Both successful and unsuccessful operator logins are audited in the system control log (>sc1>as_logs>log). If the installation parameter "operator_inactive_time" is set to a non-zero value, the system automatically logs out an operator terminal if no request is issued from that terminal for the specified period of time. (In actuality, the automatic logging out does not occur until the next operator request is entered, due to complexities in making this work asynchronously. The effect, however, is the same.) If message coordinator terminals hang up, any signed on operator is automatically logged out. Operator login is not enforced until the answering service is initialized (via a "startup" or "multics" request), and the execution of the system_start_up.ec is complete. This window is necessary since the information needed to enforce operator login may not be available until the answering service has started. Further, if problems arise in the databases responsible for enforcing operator login, there would be no mechanism for site administrators to fix them short of reloading relevant portions of the hierarchy. Operator input before the answering service is initialized, in admin mode or not, is still audited in the admin log however. The module sc_requests_ enables operator login after executing the system_start_up.ec if the installation parameter is enabled. Sc_execute_command_line_ actually enforces operator login by checking to see if the terminal is authenticated before executing the request line. The module sc_process_command_line_ (called prior to sc_execute_command_line_) performs the inactivity checks and calls mc_commands_$sign_out to log an operator out. System_control_ (the process overseer for the system control process) remains in a loop until shutdown, waiting for input on the bootload console and calling sc_process_command_line_ to execute operator request lines. mc_tty_ handles all ring-0 wakeups from message coordinator terminals and invokes sc_process_command_line_ to execute requests lines. When the sign_on operator request is issued, or when it is invoked automatically upon entering a request at a not-logged-in operator terminal, the module sc_requests_$sign_on is invoked. It reads the name and password, checks the PNT, and calls mc_commands_$sign_in to perform the actual logging in. When the 2-2 System/User Control MDD-010-01 sign_off operator request is entered, the module sc_requests_$sign_off is invoked, which in turn calls mc_commands_$sign_out. 222...333...222 CCCooonnntttrrrooolll ooofff OOOpppeeerrraaatttooorrr UUUssseee OOOfff AAAdddmmmiiinnn MMMooodddeee For those system maintenance functions which must be performed in the Initializer process, system control provides two mechanisms. The first is "admin mode", described here, and the second is the "send_admin_command" interface, described in a later section. The "admin" request, issued on any operator terminal (subject to message coordinator restriction codes, which are discussed later), will cause the terminal to be placed in "admin mode". This invokes the standard Multics listener which reads and executes Multics commands. These commands are executed in the Initializer's process, which runs with all AIM privileges enabled and SysDaemon access, effectively providing access to anything on the system. Admin mode may be protected via a password, which is set via the "set_special_password" command. If a password has been set, anyone issuing the "admin" request is queried for a password, which must match this password stored in the PNT. The dummy userid "_operator_admin_mode" in the PNT is the placeholder for the admin mode password. The module sc_admin_mode_ is responsible for checking the password and denying entrace to admin mode if it is incorrect. Normal user input and output performed by the operator while in admin mode is audited in the admin log (>sc1>as_logs>admin_log). Although this auditing may provide some level of accountability, the mechanism used to provide the auditing is not, and cannot be, completely robust. It is possible for a malicious operator to circumvent the admin mode auditing. For this reason and the fact that admin mode provides access to all user and system files, the admin mode password should be carefully guarded and distributed only to trustworthy individuals. 222...333...333 CCCooonnntttrrrooolll ooofff OOOpppeeerrraaatttooorrr AAAcccccceeessssss tttooo DDDaaaeeemmmooonnn PPPrrroooccceeesssssseeesss Operators may control the operation of system daemon processes. System control requests allow the logging in and logging out of daemons, the sending of arbitrary commands and responses to daemons, and the interruption of daemon processes through the use of the standard "quit" signal. Daemon processes may be arbitrarily privileged, and for this reason, Multics allows 2-3 MDD-010-01 System/User Control system administrators to restrict the level of control operators have over the daemon processes, by enabling the "validate_daemon_commands" installation parameter. Associated with each logged in daemon is an identifier, usually termed the "message coordinator source id", or "source id" for short. System control and the message coordinator use this source id to identify daemon processes, and the message coordinator uses it for message routing for the daemon. There can only be one daemon process associated with a given source id at any one time, from which it follows that daemon processes may be uniquely specified via the source id. Associated with every usable source id is an Message Coordinator Access Control Segment (MCACS) which specifies the access rights associated with the use of the source id. These MCACSs are located in the directory >system_control_1>mc_acs and follow the naming convention .mcacs, e.g. prta.mcacs. These zero-length segments are implemented as extended entries whose Access Control Lists (ACLs) specify the following access modes: c - (control) allows the userid to log in or out a daemon over the source id. r - (reply) allows the userid to send command (or input) lines to the daemon logged in over the source id. q - (quit) allows the userid to send a QUIT signal to the daemon logged in over the source id. d - (daemon) allows the daemon whose identify is the specified userid to be logged in over the source id. These access modes allow system administrators to control which operators may interact with which daemons, and what sort of operations may be performed on daemon processes. Additionally, it allows control over which daemons may be logged in over which source ids. In order to see how these MCACSs may be used to control operators, it is necessary to understand how operator terminals are associated with userids, and how these userids are used in MCACS ACLs. Associated with every operator terminal is an access identifier, similar to the access identifier used by normal Multics processes, and typically referred to as the "process group id". The process group consists of three parts: the person id, project id, and the tag. For operator terminal access idntifiers, the project id is always "Operator", and the tag is 2-4 System/User Control MDD-010-01 always "o", which stands for "operator". The userid specified for operator login becomes the personid field of the access identifier. Thus, if operator "Jones" logs in on an operator terminal, his access identifier becomes "Jones.Operator.o". There are a few special access identifiers worthy of mention here. "_Unidentified.Operator.o" is the access identifier for an operator terminal which has not yet been, or is no longer, logged in. If operator login is not required at a particular Multics site (i.e. the "require_operator_login" installation parameter is disabled) but daemon access control checking is active (i.e. the "validate_daemon_commands" parameter is enabled), then not-logged-in operators may be distinguished from logged-in operators for the purpose of access control via the "_Unidentified.Operator.o" MCACS ACL term. Another special access identifier is "_Exec_Command.Operator.o". This is used during the execution of an operator "exec" or "x" command (those implemented in the admin.ec). The rationale behind this special access identifier is to allow the "exec" commands to manipulate daemons in ways not directly accessible to operators. System administrators may set up canned daemon command sequences (in the admin.ec) while restricting operators from issuing arbitrary commands to the same daemon. The modules mc_check_access_ and mc_check_acs_ are reponsible for performing the access checks associated with message coordinator source ids. 222...333...444 MMMeeessssssaaagggeee CCCoooooorrrdddiiinnnaaatttooorrr (((MMMCCC))) RRReeessstttrrriiiccctttiiiooonnnsss When a Message Coordinator (MC) terminal is accepted for use (via the operator "accept" command), it may be restricted in the operations which may be performed from this terminal. All valid operator requests have restriction codes tied to them, which must be enabled for a given operator terminal before they will be executed by system control. The module sc_request_table_.alm defines all the operator commands and the associated restriction code requirements. The table of all configured operator terminals maintains the restrictions codes associated with each terminal. It is therefore possible, for example, to limit a particular operator terminal to, say, execute only status requests (like "who" and "hmu"), or only execute "exec" ("x") commands, or only "reply" to daemons, or combinations of these restrictions. 2-5 MDD-010-01 System/User Control The setting of MC restrictions is performed by the module mc_commands_$new_tty when a MC terminal is accepted. These restrictions are checked against the those required for execution of an operator request by sc_execute_command_line_. Which restrictions apply for a particular request are delineated in the sytem control request table, sc_request_table_. 222...333...555 AAASSS RRReeeqqquuueeesssttt SSSeeerrrvvviiiccceee The facility known as the "Answering Service (AS) Request Subsystem" is misnamed. It is a service provided by the Initializer process for handling requests from user processes to perform operations that must be executed by the Initializer (system control) process. None of these requests is really an "answering service" request; rather each falls more accurately into the category of "system" or "user" control requests. Those "system control" requests which make access control decisions and enforce some security policy will be discussed in this subsection, while those which more natually align themselves with "user control", will be left for the section on user control. Before proceeding to security issues specific to particular AS requests, some discussion of AS request handling in general is necesary. An AS request is communicated from a user process to the system control process through the use of a message, placed in a special message segment, and an Inter Process Communication (IPC) signal. The security policy enforced by the message segment software is crucial to the secure operation of the AS request mechanism. The IPC signal serves only to notify the system control process of a pending request and otherwise is ignored. The message segment software provides the system control process with the identity and security attributes of the sending process, e.g. person id, project id, process id, process authorization, process maximum authorization, and validation level of sending process. The access control decisions made by the individual AS requests depend on the accuracy of these security attributes. The AS request software is placed into action upon receipt of an IPC wakeup over a publicly advertised event channel. As mentioned earlier, this wakeup serves only to notify the system control process of a pending request. The module as_request_server_ handles the wakeup and successively reads, processes, and deletes messages out of the AS request message segment (>sc1>as_requests.ms). As each request is processed, security checks may be made (unless the request manipulates per-process only data or attributes) and success or failure of those security checks are audited in the system control log (>sc1>as_logs>log). The specific security checks performed for 2-6 System/User Control MDD-010-01 the various types of AS requests are discussed in their own subsections. Only two of these request types are considered "system control requests"; they are discussed here. The other request types are covered in the section entitled "Security Issues in User Control." AS REQUEST: SEND_ADMIN_COMMAND One of the services of system control provides user processes with the capability to send arbitrary command lines to the system control process (Initializer) for execution. This is, of course, a very privileged interface and access to use it controlled very tightly. In order to use the facility, the user process must have Read-Write (RW) discretionary access to the Access Control Segment (ACS), >sc1>admin_acs>send_admin_command.acs. These checks are performed by the module sc_admin_command_. The "process group id" and validation level provided by the message segment software are used to check the effective access to the ACS segment. If the correct access exists, the command line is audited in the system control log and executed within the system control process. Output from the command is logged as well. If the requisite access does not exist, the access denial is audited in the log. Two types of commands may be executed in the system control process with this request: normal Multics commands, or operator requests. For either type, any access control checks are made on behalf of the system control process, whose process group id is "Initializer.SysDaemon.z". Operator requests which manipulate daemons undergo similar access control checks as those discussed in the section on operator control of daemon processes although the process group id involved in the MCACS ACL checks is that of the Initializer. It should be stressed that the sending process' AIM authorization is not factored into the access checks made by this request. A process which otherwises passes the access checks discussed above may send arbitrary commands to the system control process regardless of its AIM authorization. This is intentional because of the very privileged nature of this request. AS REQUEST: SEND_DAEMON_COMMAND This AS request allows user processes to control the operation of daemon processes. Daemon processes may be logged in or out, sent QUIT signals, or sent arbitrary input (command) lines. As with the Send_Admin_Command request type, this is a very privileged interface. The access control checks made depend on the setting 2-7 MDD-010-01 System/User Control of the installation parameter "validate_daemon_commands". If disabled, the access checks directly parallel those of the Send_Admin_Command request except that the ACS segment used is >sc1>admin_acs>send_daemon_command.acs and the module involved is asr_daemon_command_server_. All issues discussed in the previous subsection apply in this case. If validate_daemon_commands is enabled, however, a much finer degree of control may be exercised. The ACS segment mentioned above is not used in access control decisions. The access checks directly parallel those discussed in the section "Control of Operator Access to Daemon Processes". The MCACS segments are used for checking access to control a particular daemon process, identified by the "source id", and the access identifier used is that of the process which submitted the Send_Daemon_command request. This allows system administrators to grant very specific daemon control privileges to arbitrary users. The modules which perform the access checks when validate_daemon_commands is enabled are mc_check_access_ and mc_check_acs_, the same ones involved in control of operator-daemon interaction. As in the case of the Send_Admin_Command requests, the AIM authorization of the process submitting Send_Daemon_Command requests does not become involved. This allows a process which otherwise passes the access checks described above, to affect daemon processes at higher or lower authorizations. This is intentional due to the very privileged nature of this request. 222...444 SSSEEECCCUUURRRIIITTTYYY IIISSSSSSUUUEEESSS IIINNN UUUSSSEEERRR CCCOOONNNTTTRRROOOLLL 222...444...111 IIIdddeeennntttiiifffiiicccaaatttiiiooonnn aaannnddd AAAuuuttthhheeennntttiiicccaaatttiiiooonnn (((III&&&AAA))) Before users are allowed access to the system, they are identified and authenticated by the user control (Initializer) process. The (I&A) access checks vary slightly for interactive, absentee, and daemon users and depend upon the type of system access involved (e.g. login, slave, dial, and ftp service). This different user and access types are discussed separately, and subsequent sections draw upon discussion presented in previous sections, and suggest reading the material in the order presented. One module, lg_ctl_, however, is responsible for providing consistent I&A checks for all types of users. 2-8 System/User Control MDD-010-01 INTERACTIVE USER I&A When interactive users establish initial contact with Multics, a dialog between the user (or a login server intermediary) and the user control process (Initializer) begins. The type of service required (login, slave, dial, ftp) directs the I&A sequence. The first three service types are identified by the preaccess command typed by the user. The fourth, ftp service, is implied by the service type of the communications channel, as specified in the Channel Definition Table (CDT). The "login" service type is discussed first. Interactive login I&A involves first determining the identity of a user requesting access to the system, and then authenticating that identity with a password and entries in various administrative tables. If the criteria for a successful I&A are not met at any time during the I&A process, the I&A is rejected and a "LOGIN DENIED" audit message logged in the system control log, >sc1>as_logs>log. Successful I&A's result in a "LOGIN" audit entry in the log. Interactive logins may be normal or "anonymous". Anonymous logins are discussed in a subsequent section. For normal logins, the identify of a user consists of both a "person id" and a "project id". The person id must be registered in the Person Name Table (PNT), a TCB-controlled administrative database, and the password contained therein must match the password provided by the user at I&A time. If the PNT entry for the user specifies the password as "locked" (lock flag), the login is refused. If the entry has its "trap" flag enabled, the login is accepted but a message is logged and printed on the system console to notify system personnel of the password's use. Password Manipulation Various control arguments specified during the login dialog specify whether the user wishes to change his password, have the system generate a new password, or override some of the default parameters associated with logging in. The PNT entry specifies whether a user may change his password (change flag) and whether the user may specify a password or must have it generated automatically by the system (generate_pw flag). The PNT entry further specifies whether the user must change his password (must_change flag). If the must_change flag is enabled for the user, and the "-change_pw" (-cpw) or "-generate_pw" (-gpw) control arguments are not specified, the login is rejected with a message and the user must try again. 2-9 MDD-010-01 System/User Control Password Management Policy Various installation parameters impose other restrictions on passwords and logging in. The "password_change_interval" parameter places an upper limit on the time interval between password changes. If the user has not changed his password in the specified period of time, he is forced to change it. The "password_expiration_interval" parameter restricts the length of time passwords may go unused. If a password has not been used in the specified period of time, the login is refused, and system administrator intervention is required before the user can log in. If the user requests a password change, and is otherwise allowed to do so, the "password_min_length" parameter specifies a minimum length for the user generated password. The "password_gpw_length" specifies the length of system generated passwords. If all the password checks succeed, the PNT entry is updated with the current time, indicating when the password was last used successfully. Incorrect Passwords If the user-supplied password does not match the password stored in the PNT, the login is rejected. Further, the PNT is updated with the current time, indicating when the password was last used unsuccessfully, and the number of bad passwords is incremented. The user whose password was used unsuccessfully is notifed via interactive message and a flag set in the PNT which directs the I&A process to notify the user upon next successful login of the previous bad password attempts. Physical Security Breaches Once password validation and processing is complete, the system may check for a possible security breach of mandatory access control policy. Associated with all login communications channels is an access class range, defined in the Channel Definition Table (CDT). If the "audit" flag (in the CDT entry) is enabled for the user's communications channel, the user's maximum authorization, as specified in his PNT entry, must be greater or equal to the minimum access class of the login channel. If this condition is not satisfied, the login is refused and a message alerting system personnel to the possible security breach is displayed on the system console. System administrators may, therefore, restrict certain terminals (such as those in a secure area) to users who possess the requisite security clearance (maximum PNT authorization). 2-10 System/User Control MDD-010-01 Project Id Validation After all the above checks are made, the project id is validated. The user specified project id (or the default project id in the user's PNT entry) must correspond with an active project defined in the System Administrator Table (SAT). Further, the Project Definition Table (PDT) for the specified project must list the person id as a registered member of the project. Communications Channel Access Once the user is identified and authenticated by person id and project id, an access check may be made to determine whether the user has access to login on the communications channel he is using. The "login" attribute of the "check_acs" statement for the CDT entry for the channel, if enabled, ensures this check is made. In this case, the user must have RW access to the ACS segment for the channel. The ACS segment resides in the directory >sc1>rcp and is named .acs, e.g. >sc1>rcp>a.h001.acs. If either this ACS segment does not exist, or the user does not have access to it, the login is denied and and audit message entered into the log. AIM Authorization Checks and Audit Flags The AIM checks are made next. The user's login command line may specify the authorization at which he wishes to log in with the "-auth" control argument. If not specified, the user's default authorization (stored in his PNT entry) becomes the desired authorization. The user's allowable authorization range is calculated and the desired authorization compared to this range. If it is outside the calculated range, the login is denied and audited. The allowable authorization range is calculated as follows: The user's allowable maximum authorization becomes the minimum of the user's maximum authorization in the PNT, the project's maximum authorization in the SAT, the user's maximum authorization in the PDT, and the communication's maximum access class as specified in the CDT. In a similar manner, the user's allowable minimum authorization becomes the maximum of the user's minimum authorization in the PNT, the project's minimum authorization in the SAT, the user's minimum authorization in the PDT, and the communication's minimum access class in the CDT. This results in the most restrictive authorization range allowed by the PNT, SAT, PDT, and CDT. The process audit flags are set to the logical "or" of the audit flags as specified in the PNT for the personid and those specified in the SAT for the project id. 2-11 MDD-010-01 System/User Control Initial Login Ring There is one final security check performed upon login which involves verifying that the login ring, specified on the login command line, or taken either as system-wide or PDT-specified default, is valid. The login ring is the initial ring at which the process runs. The specified, or default ring must be less than or equal to the maximum of the SAT-defined and PDT-defined minimums. The maximum ring in which the process may run becomes the minimum of the SAT-defined and PDT-defined maximums. If the user-specified login ring is too low, the login is rejected and an audit message generated. Connecting to Disconnected Processes When an interactive user is disconnected (usually because his terminal of communication channel has hangup) his process may become disconnected rather than being logged out. System administrators may control this facility through the save_on_disconnect and disconnect_ok user attributes. When the user logs in again, he may or may not be connected to the system over a channel which would allow him (due to the channel's access class range) to connect to his disconnected process. The module dialup_ which processes the initial pre-access dialog, and actually performs the process reconnection, performs a check to ensure the communications channel allows access to the process. If it does not, i.e. process authorization is outside the access class range of the channel, the connect preaccess request is refused and the denial is recorded in the system control log. Anonymous Interactive User I&A Anonymous user logins proceed in a similar manner as normal user logins with several modifications. The passwords associated with anonymous logins are stored in the PDT for a particular project, rather than in the PNT. The password may be optional, as well, its existance and setting determined by the project administrator. In order to login as an anonymous user, the "enter" (e) or "enterp" (ep) preaccess commands are used. The former is used for anonymous logins with no passwords, and the latter, when a password is required. Anonymous users may not change their passwords, and the password change and expiration time limits do not apply. Since there is no PNT entry associated with an anonymous login, the bad password notification and metering of bad password attempts in the PNT is not performed. The default project id for an anonymous user, if not specified, is identical to the specified person id. This default is historical and is of dubious utility. When a process is created for an anonymous user, the "process group id", used in access checking is set to "anonymous..a". It is therefore 2-12 System/User Control MDD-010-01 possible to deny access for anonymous users to storage system and other objects by specifying null access Access Control List (ACL) terms for "anonymous.*.*". Anonymous users may log in at system_low authorization only; their minimum and maximum authorizations are also set to system_low. All of the AIM-related access checks described in the previous section are made, although the anonymous user has no way to specify any authorization besides system_low. The audit flags associated with anonymous users are those specified in the SAT for the project. Interactive 'dial' service I&A In addition to "login" service, an interactive user may initiate a "dial" service. More accurately, he may request to have his communications channel connected to an already logged-in process which will gain control of the channel. The process which becomes the target of the dial is either specified explicitly on the dial command line or is implicit through the use of registered dial servers. When a process begins "serving dials", it specifies whether to begin an unregistered or registered dial service. Whether registered or registered dial service is involved is irrelevant to I&A, however. If the "slave_dial" attribute of the "check_acs" keyword is enabled for the communications channel over which a dial is attempted, an I&A check, similar to that for normal login, is performed. Otherwise, no I&A takes place. When the slave_dial attribute is enabled, the dialing user must use the "-user" control argument to the "dial" command to specify a person id and project id. These are used to perform the I&A in a similar manner to that for a normal login. The default authorization in the PNT for the person id, or the authorization specified via the "-auth" control argument to the "dial" command must lie within the access class range of the channel. If the communications channel is defined as multi-class, it becomes single-class after I&A at the specified or default authorization. Further, this authorization must match the authorization of the process being dialed to unless the target process has the "comm" system privilege enabled. The initial login ring and maximum ring checks performed for login service do not apply for dial service. In addition to the LOGIN audit message which all I&A's produce, a DIALIN audit message is logged indicating to which dial id and process a user has dialed. 2-13 MDD-010-01 System/User Control Interactive 'slave' Service I&A Slave service for a terminal is initiated by the "slave" preaccess command. It places the communications channel in a state (slave state) so that a process with the appropriate access may attach it for use as a auxilliary communications channel (e.g. for printers). The "slave" preaccess command is rarely used, however, because it is possible to configure dedicated communications channels in the slave state in the Channel Definition Table (CDT). If the "slave_dial" attribute of the "check_acs" statement is enabled for a specified communications channel in the CDT, then attempts to start a slave service on the channel will undergo an I&A in an similar manner as for dial service. The "-user" control argument specifies the personid and project id for the I&A. A password is solicited from the user and verified. The default authorization in the PNT entry for the specified person id may be overiden by an "-auth" control argument to the "slave" preaccess command. This authorization, of course, must lie within the limits imposed by the PNT, SAT, PDT, and CDT. The channel, if previously a multi-class login channel, becomes a slave channel at the access class corresponding to this computed authorization. That is, it becomes single-class. Interactive 'ftp' Service I&A I&A for ftp service channels is identical to that for login service channels. It is mentioned in its own section, briefly, only because it may not be obvious how ftp service is initiated. Each communications channel defined in the CDT has an associated service type. Channels with the service type of "login" undergo an interactive dialog allowing for various preaccess commands (like "login", "dial", "slave", "ttp", "modes", etc.). Channels with the service type of "ftp" are handled by a specialized procedure which interprets commands defined by the File Transfer Protocol (FTP) networking protocol and executes these commands. This special procedure (ftp_dialup_), however, calls the same I&A module (lg_ctl_), that is invoked for login service channels. DAEMON USER I&A I&A for daemon processes is performed in a similar manner as for interactive user logins. A few significant differences, however, are noteworthy. Daemon processes may be logged in via operator command, or through either of the Send_Admin_Command or the Send_Daemon_Command facility described previously. The security 2-14 System/User Control MDD-010-01 policies for these methods of initiating daemon login have already been discussed. Whichever method is used to log in daemons, the module daemon_user_manager_ performs the actual login. It calls lg_ctl_$daemon_in to perform the I&A checks. Daemon user I&A is identical to interactive user I&A with the following exceptions. ox There is no password associated with a daemon login. The decision to allow or disallow a given operator or user to log in the daemon has already been made by this point. ox Anonymous daemons are not allowed. ox The "daemon" attribute for the project (specified in the SAT) and for the user (specified in the PDT) must be enabled. ox The ACL of the MCACS segment for the daemon source id associated with the daemon process must allow "d" access for the daemon's process group id (Personid.Projectid.z). ABSENTEE USER I&A Absentee processes are managed by the module absentee_user_manager_ and its associate, absentee_utility_. The I&A process is very similar to that of interactive users with the exception that there is no password and all the password checks are skipped. The module which performs the I&A is lg_ctl_$abs_in. The person id and project id for the absentee login are determined from the absentee request submitted by the user. These in turn are maintained in a secure fashion by the message segment facility. The authorization at which the absentee process is to log in is specified by the user in the absentee request. absentee_utility_ ensures this authorization is greater than or equal to the authorization of the process which submitted the request. If it is not, it is upgraded to the authorization of the sending process. lg_ctl_$abs_in, in the same manner as for interactive logins, ensures this authorization is within the allowable ranges specified in the PNT, SAT, and PDT. Because there is no communications channel involved in an absentee login, the CDT access class checks do not apply. 222...444...222 PPPrrroooccceeessssss CCCrrreeeaaatttiiiooonnn The User control process (Initializer) is the only one which creates other processes. It does so by calling the user 2-15 MDD-010-01 System/User Control control module cpg_, which after performing various initialization steps, calls the hardcore (Ring-0) entrypoint, hphcs_$create_proc, which actually creates the process. The various security related attributes, like the person id, project id, process authorization, process maximum authorization, login ring and maximum ring are passed to the hardcore in the call to hphcs_$create_proc. These security attributes are stored in the process's Process Descriptor Segment (PDS) and are used for various access checks in hardcore. They, and other non-security related attributes are also stored in the Process Initialization Table (PIT) template maintained by the Initializer process. A pointer to this table is passed to the hardcore in the call to hphcs_$create_proc so that its contents may be placed in the newly-created process directory for the process. Since the PIT is readable by the new process, this allows the process to determine various attributes about itself. The process group id, used by the TCB in all access decisions, is created by the program cpg_. It is constructed from the person id, project id, and tag supplied or inferred at I&A time. If the login is an anonymous one, then the person id portion of the process group id is set to the string "anonymous" rather than the person id specified on the login line (for interactive logins) or in the absentee request (for absentee logins). When a process is created, cpg_ logs an audit record in the system control log with the various security attributes contained within the binary portion of the audit message. 222...444...333 PPPrrroooccceeessssss DDDeeessstttrrruuuccctttiiiooonnn Once a process is created, an event channel is set up to allow the process (in either the user ring or in ring-0) to signal a request for process termination to the user control process. The user process may, at its discretion, request a logout or new process. Ring-0 may cause process termination as well, as in the case of a fatal process error. In any case, user control, in either the dialup_, ftp_dialup_, daemon_user_manager_, or absentee_user_manager_ modules (corresponding to appropriate process type) handles the wakeups over this process termination event channel. In order to ensure that a process can only affect itself and no other process, a few validity checks are made at wakeup time. Associated with any IPC wakeup is some security information about the sender of the wakeup. The sender process id and validation level, in conjunction with 2-16 System/User Control MDD-010-01 information available in system tables, allow the user control process to determine that the wakeup, which occured over a per-process event channel actually came from the process associated with the event channel. The validation level allows the user control process to distinguish between user-ring and Ring-0 events. The event handler for the process termination channel ensures that signals that should only originate from Ring-0 (such as a terminal hangup) are not being sent from the user-ring, or that signals that should only originate from the user control process (such as channel detachments requests) do so. Users may signal various conditions to the user control process. Most of these have to do with ending the login session. Some cause a new process to be created after the old one is destroyed. One signal, the "new_proc -auth" signal, allows the creation of a new process with a change in process authorization. In this case, the requested authorization is compared against the process's allowable authorization range. If the new authorization is within the range, the process is created at this authorization. If outside the range, the process is created at the old authorization and the user receives a message indicating this has occurred. A site may disallow the use of "new_proc -auth" to change process authorizations. The installation parameter "trusted_path_login" serves two functions. First, it disallows changing process authorizations without logging out and logging in again (and therefore enforces another I&A. Second, it disallows making use of the "logout -hold" feature to return the user to the I&A dialog. This installation parameter is the mechanism used to enforce the use of a "trusted path". On Multics, the only assurance one has that the I&A dialog is undertaken with trusted software (the answering service) as opposed to with a trojan horse, is after first having broken the communications channel connection and reconnected it. A site may wish to ensure that a trusted path exists before allowing a change in authorization or user identity and it is through the "trusted_path_login" installation parameter that this is accomplished. All of the allowed signals from the user process affect only that process. Any illegal signals or those that may be sent only from Ring-0 or from the user control process cause the user process to be terminated. The user is apprised of his error. 2-17 MDD-010-01 System/User Control 222...444...444 AAASSS RRReeeqqquuueeessstttsss A previous section introduced the AS request subsystem. General security issues which applied to all AS request were discussed. In the following sections, the security issues particular to specific AS requests are examined. AS REQUEST: DIAL SERVICE The "dial service" AS request is another misnomer. It provides a means for a user process to request various operations which are listed below. All access control decisions for these requests are made by the module dial_ctl_. ox begin dial service ox end dial service ox release a dial id ox attach a communications channel ox detach a communications channel The access control checks enforced by user control vary from sub-request to sub-request. Begin Dial Service This request allows the user process to begin a dial service for a specified "dial id". If the dial service is successfully started, users may "dial" to the serving process as an alternative to logging in and creating their own process. Dialing to a process is initiated via the "dial" preaccess command issued upon initial contact with the Multics answering service. The "dialing" channel becomes a slave channel for the process providing the dial service, and remains in control of that process until the channel hangs up. In order to begin a dial service, the process issuing the request must have the "dialok" attribute. Attributes are set for a process at process creation time from a combination of the attributes allowed for a project (in the SAT) and for the user (in the PDT). The request is rejected and logged if this attribute is not enabled for the process. 2-18 System/User Control MDD-010-01 A dial service may be either registered or unregistered. A registered dial service allows users to dial to the process by specifying only the "dial id". An unregistered service requires specification of both the dial id and the person id/project id of the process providing the service. In order to begin a registered dial service, the requesting process must have RW access to the ACS segment in >sc1>rcp named dial..acs, for example, >sc1>rcp>dial.foo.acs. A dial service may be privileged or unprivileged. A privileged dial service allows dials from communications channels of equal or greater access class than the authorization of the process serving dials. Unprivileged dial service requires the process authorization to be within the access class range of the dialing communication channel. If I&A is enabled for channels dialing in to dial servers, the access class of the dialing channel will become single-class (if it wasn't already) which effectively ensures that non-privileged dial servers may only attach channels whose access class is equal to the server process authorization. In order to become a privileged server, the requesting process must have the "comm" system privilege enabled, or initiate the request from Ring-1. Stop Dial Service This request allows a dial server to stop serving dials and to disconnect all communications channels dialed to the process. The only access check performed ensures the process has the "dialok" attribute and is the server for that dial id. All channels which have dialed to the process are hung up. Release Dial Id This request allows a dial server to stop serving dials but not disconnect all communications channels dialed to the process. The only access check performed ensures the process has the "dialok" attribute and is the server for that the specified dial id. Attach Channel This request allows a process to attach auxilliary communications channels and requires the "dialok" attribute. There are two types of attachments: regular and T&D. Regular attachments require the user to have RW access to 2-19 MDD-010-01 System/User Control the ACS segment >sc1>rcp>.acs, e.g. >sc1>rcp>a.h000.acs, if the channel's "priv_attach" check_acs flag is enabled. Otherwise no particular access is required. T&D attachments additionally require RW access to the ACS segment >sc1>admin_acs>tandd.acs. Regular attachments may only be made to channels whose service type is "slave" (as defined in the CDT). T&D attachments may be made regardless of service type and cause the channel, if in use, to be hung up before attachment. The requesting process's authorization must be within the access class range of the channel unless the comm privileged is enabled. If enabled, the process's maximum authorization must be greater than or equal to the maximum access class of the channel. Release Channel This request detaches a specified auxilliary communications channel from the process. In order to release a channel, the process must have the dialok attribute. An option of this request is to prevent the answering service from listening to this channel automatically. This option may only be used if the channel attachment was a T&D attachment. AS REQUEST: DIAL-OUT SERVICE Dial-Out Channel This request allows a user to dial-out an auxilliary communications channel. The dial-out operation allows specification of a destination to which the channel is to be connected. Autocall modems and network connections are typical examples of dial-out channels. Dialing out a channel requires the dialok attribute. This check and other security checks described below are performed by the module dial_ctl_. When dialing out, the user may specify an access class to select an appropriate dial-out channel. This access class must be equal to the process' authorization, or, if the comm privilege is enabled, may be greater than or equal to the process authorization. If the "dial_out" check_acs flag is enabled for a particular channel, the requesting process must have RW access to the ACS segment >sc1>rcp>.acs, e.g. >sc1>rcp>a.h001.acs. In addition, the requested access class must lie within the access class range of the channel. 2-20 System/User Control MDD-010-01 If the channel is a multi-class channel, it becomes single-class, at the requested access class until it is hung up or detached. Terminate Dial-Out Channel This request is used to terminate a existing dial-out connection. Other than ensuring the specified channel is actually dialed out for the process, there are no access checks made by this request. AS REQUEST: FATAL PROCESS ERROR HANDLING Two AS requests allow a process to indicate to user control, what action to take on a fatal process error. One request specifies that a fatal process error should cause a logout, and the other, that a new process is to be created. These AS requests handle per-process attributes and cannot be used to affect any other processes. There is no access control on these requests. AS REQUEST: PROCESS TERMINATION MONITOR Privileged processes may ask user control to notify them when processes are destroyed. This is useful for those system processes which are required to "clean up" after processes when they are destroyed (for whatever reason). In order to register one's process as a "process termination monitor", the requesting process is required to have RW access to the ACS segment >sc1>admin_acs>process_termination_monitor.acs. If this access does not exist, the request is rejected and an audit message produced. These checks are performed by the module dpg_. AS REQUEST: BUMP USER Privileged processes may request user control to bump other users. The access requirements for this request are that the requesting process must have RW access to the ACS segment >sc1>admin_acs>bump_user.acs. If the process does not have this access, the request is rejected and an audit message logged. These checks are performed by the module as_request_bump_user_. 2-21 MDD-010-01 System/User Control AS REQUEST: NOTE PNT CHANGE When a system administrator changes the authorization range for a user in the PNT, and that user is logged in at an authorization outside the new range, the system will bump the user automatically. This is accomplished through the use of this AS request. The PNT software is part of the TCB and runs in Ring-1. Therefore the only access check made by this request is to ensure the request is initiated from Ring-1. This is performed by the module as_request_note_pnt_change_. The message segment software, from which the request is retrieved, includes the validation level of the sending process, providing assurance that only processes running in Ring-1 may successfully invoke this request. A message is logged in the system control log whenever this request causes a user process to be bumped or whenever the request does not originate from Ring-1. AS REQUEST: COMMUNICATIONS CHANNEL INFO This request allows a user to learn various security attributes about either his login communications channel, or any channel attached to his process. This request is particularly useful for determining the identify of a user who has "dialed" to the process, given that the channel required an I&A. The only access requirements for this request are that the specified channel must either be the primary login channel or one which has been attached, dialed out, or dialed in to the process. The user is denied information about other channels. This policy is enforced by the module asr_comm_channel_info_srvr_. 222...444...555 AAAbbbssseeennnttteeeeee FFFaaaccciiillliiitttyyy There are several security aspects of the absentee facility which warrant discussion. The absentee facility, in general, is responsible for processing requests in the absentee queues. The queues are implemented as Ring-1 message segments, and maintain, in a secure fashion, information about the process which added the request to the queue. The person id, project id, process id, validation level, process authorization, and process maximum authorization are among those items which can be guaranteed to be unforgeable by user processes. The credibility of this information is crucial to the security of the absentee facility. Absentee processes are logged in with the person id and project id of the submitter of the absentee request. The I&A performed for absentee processes, described previously, depends on the validity of this information. 2-22 System/User Control MDD-010-01 The absentee facility receives AS requests by which users | may signal the absentee manager that an absentee request has been submitted, or that a running absentee is to be cancelled. The first signal has no access implications, as it just causes the absentee user manager to search for requests in the queues. It conveys no other information. The cancel signal, however, ensures that the absentee request id does, in fact, belong to the user who did the signalling and that the authorization of the absentee process matches the authorization of the user. | These checks are performed by the module | absentee_utility_ in tandem with asr_abs_command_server_. | An event channel is used by the operator interface to run, | suspend, release, and cancel absentees. The absentee | facility (absentee_user_manager_) uses the security information provided by the IPC facility, to ensure that the operator requests are only sent by the system control process. 222...444...666 AAAdddmmmiiinnniiissstttrrraaatttiiivvveee TTTaaabbbllleee IIInnnssstttaaallllllaaatttiiiooonnn The Answering Service maintains an event channel over which system and project administrators may request the installation of copies of the various administrative databases. These include the following tables: the System Administrator Table (SAT), Project Definition Table (PDT), Resource Type Description Table (RTDT), Master Group Table (MGT), and Channel Definition Table (CDT). The module up_sysctl_ is responsible for determining the type of table installation and calling the appropriate module to perform the actual merging of the new table and the currently installed table. In order to install the SAT, RTDT, MGT, and CDT, the user requesting the installation must have RW access to the appropriate ACS path in the directory >sc1>admin_acs. The ACS segments are named sat.install.acs, mgt.install.acs, rtdt.install.acs, and cdt.install.acs and correspond to the similarly named tables. If the user does not have appropriate access to perform the installation, an audit message is recorded in the system log. The modules responsible for installing a particular table type, i.e. up_sat_, up_rtdt_, up_mgt_, and up_cdt_ each perform the appropriate access check. Project Definition Table (PDT) installations undergo a different security policy. In order to install a PDT for a particular project, the installer must either be a system administrator (on the list of system administrators contained in the SAT) or a project administrator for the 2-23 MDD-010-01 System/User Control project (on the list of project administrators in the definition for the project in the SAT). This check is performed by the module up_pdt_. ----------------------------------------------------------- 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