MULTICS DESIGN DOCUMENT MDD-029 To: MDD Distribution From: Jim Lippard Date: May 12, 1988 Subject: Security Auditing Abstract: Describes the system security audit trail. Some descriptions in this document are dependent upon the contents of MDD-024 "System Logging". Revisions: REVISION DATE AUTHOR initial 86-02-01 Ed Sharpe 1 88-05-12 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-029 Security Auditing CONTENTS Page Section 1 Introduction . . . . . . . . . . . . . . 1-1 Section 2 Goals . . . . . . . . . . . . . . . . . . 2-1 Logging Security Related Events . . . 2-1 Perusal of the Audit Trail . . . . . . 2-1 Meeting Orange Book Requirements . . . 2-1 Section 3 Overview . . . . . . . . . . . . . . . . 3-1 Use of System Logs . . . . . . . . . . 3-1 Audit Modules . . . . . . . . . . . . 3-1 Operation Description . . . . . . . . 3-1 Object Name . . . . . . . . . . . . 3-1 Object Access Class . . . . . . . . 3-2 Operation Code . . . . . . . . . . 3-2 Object Class . . . . . . . . . . 3-2 Operation Type . . . . . . . . . 3-3 Unique Index . . . . . . . . . . 3-3 Operation Status . . . . . . . . . 3-3 Operation Mode . . . . . . . . . . 3-3 Audit Trail Selectivity . . . . . . . 3-4 System Audit Flags and Thresholds . 3-4 Per-Process Audit Control . . . . . 3-5 | Per-Object Audit Control . . . . . 3-5 Object Audit Levels . . . . . . 3-6 Operation Mode Auditing . . . . 3-6 Algorithm for Determining Whether to Audit . . . . . . . . . . . . . . . . 3-7 Major Programmatic Interfaces . . . . 3-8 access_audit_ . . . . . . . . . . . 3-8 access_audit_r1_ . . . . . . . . . 3-9 access_audit_gate_ . . . . . . . . 3-9 as_access_audit_ . . . . . . . . . 3-9 Command Interfaces . . . . . . . . . . 3-9 (new_user new_proj edit_proj admin_util) . . . . . . . . . . . 3-9 (display set edit)_process_audit_flags . . . . 3-9 (display set)_system_audit_flags . 3-9 (print summarize monitor)_sys_log . 3-10 ii Security Auditing MDD-029 CONTENTS (cont) Page Section 4 Implementation . . . . . . . . . . . . . 4-1 Data Structures . . . . . . . . . . . 4-1 access_audit_encoded_op.incl.pl1 . 4-1 access_audit_eventflags.incl.pl1 . 4-2 access_audit_user_info.incl.pl1 . . 4-3 access_audit_flags.incl.pl1 . . . . 4-4 access_audit_names.incl.pl1 . . . . 4-6 access_audit_bin_header.incl.pl1 . 4-6 access_audit_binary_def.incl.pl1 . 4-8 access_audit_meter_info.incl.pl1 . 4-8 Message Text Format . . . . . . . . . 4-9 System Constants and Variables . . . . 4-10 access_operations_.alm . . . . . . 4-10 sys_info . . . . . . . . . . . . . 4-11 pds$audit_flags . . . . . . . . . . 4-12 sat.project(N).audit . . . . . . . 4-12 pnt_entry.audit . . . . . . . . . . 4-12 sys_admin_data.default_audit_flags 4-12 pds$no_audit_ring1_fs_object_ops . 4-12 active_hardcore_data$audit_ring1_fs_ob4j-1ec3t_ops active_hardcore_data - Metering Data . . . . . . . . . . . . . . . 4-13 Modules . . . . . . . . . . . . . . . 4-14 access_audit_.pl1 . . . . . . . . . 4-14 access_audit_r1_.alm . . . . . . . 4-16 access_audit_gate_.alm . . . . . . 4-16 access_audit_check_ep_.alm . . . . 4-16 access_audit_log_fault_.pl1 . . . . 4-16 access_audit_util_.pl1 . . . . . . 4-17 as_access_audit_.pl1 . . . . . . . 4-17 set_system_audit_flags.pl1 . . . . 4-18 hphcs_ Entries . . . . . . . . . . 4-18 set_sys_audit_thresholds_.pl1 . . . 4-18 merge_access_audit_flags_.pl1 . . . 4-18 admin_gate_$admin_level_no_fs_audit 4-18 convert_MR10_2_audit_flags_.pl1 . . 4-18 expand_access_audit_msg_.pl1 . . . 4-19 expand_XXXXX_audit_info_.pl1 . . . 4-19 convert_access_audit_flags_.pl1 . . 4-19 set_process_audit_flags.pl1 . . . . 4-20 Other Modules That Perform Auditing . 4-20 lg_ctl_.pl1 . . . . . . . . . . . . 4-20 page_error.alm . . . . . . . . . . 4-20 nonstandard messages . . . . . . . 4-20 Section 5 Meeting Orange Book Requirements . . . . 5-1 Maintaining the Audit Trail . . . . . 5-1 iii MDD-029 Security Auditing CONTENTS (cont) Page Events to be Audited . . . . . . . . . 5-1 I&A . . . . . . . . . . . . . . . . 5-1 Introduction of Objects into Address Space . . . . . . . . . . 5-2 Object Deletion . . . . . . . . . . 5-2 Operator and Administrator Operations . . . . . . . . . . . . 5-2 Over-Ride of Markings . . . . . . . 5-2 Covert Channels . . . . . . . . . . 5-3 Other Events . . . . . . . . . . . 5-3 Audit Trail Contents . . . . . . . . . 5-3 Audit Trail Selectivity . . . . . . . 5-4 Guidelines for Auditing . . . . . . . 5-4 Subsystem Considerations - The Access Kernel . . . . . . . . . . 5-6 Section 6 Security . . . . . . . . . . . . . . . . 6-1 Section 7 Future Enhancements . . . . . . . . . . . 7-1 Metering . . . . . . . . . . . . . 7-1 Listing Access Operations Table . . 7-1 Security Trail Perusal Tools . . . 7-1 Per-object Audit Control Flags . . 7-1 Appendix A access_audit_ Documentation . . . . . . . A-1 access_audit_$check_* . . . . . . . . A-1 access_audit_$check_general(_user) A-3 access_audit_$check_obj_class_range(_uAs-3er) access_audit_$check_obj_class(_user) A-3 access_audit_$check_obj_path(_user) A-4 access_audit_$check_obj_ptr(_user) A-4 access_audit_$check_entry_ptr(_user) A-4 access_audit_$log_* . . . . . . . . . A-5 access_audit_$log_general(_user) . A-6 access_audit_$log_obj_class_range(_useA-r)7 access_audit_$log_obj_class(_user) A-8 access_audit_$log_obj_path(_user) . A-8 access_audit_$log_obj_ptr(_user) . A-9 access_audit_$log_entry_ptr(_user) A-9 access_audit_$log_no_process . . . A-10 access_audit_util_$* . . . . . . . . . A-10 access_audit_util_$get_meters . . . A-10 access_audit_util_$get_audit_flags A-10 access_audit_util_$set_audit_flags A-10 iv Security Auditing MDD-029 SECTION 1 INTRODUCTION This document describes the function and implementation of the security auditing mechanisms in Multics. It describes the program interfaces which cause the audit trail to be generated, and the administrative controls. The reader should also see the section "Security Auditing" in the "Multics System Administration Procedures" manual order no. AK50 (as of this writing rev 03 addendum A). It contains information not duplicated in this document. The reader may also be interested in the original design specifications detailed in MTB-679 and MTB-692. However, the material there is obsolete and should be considered only for historical purposes. This document supercedes these two MTBs. 1-1 Security Auditing MDD-029 SECTION 2 GOALS This section describes the goals of security auditing. _L_O_G_G_I_N_G _S_E_C_U_R_I_T_Y _R_E_L_A_T_E_D _E_V_E_N_T_S It is not enough for a computer system to control the sharing of information. It is also important to maintain records of interesting security related events. System security administrators use these records to: - Note attempts to circumvent security. - Note potential exploitation of covert channels. - Note successful access to important objects. _P_E_R_U_S_A_L _O_F _T_H_E _A_U_D_I_T _T_R_A_I_L The system security administrator must have tools to allow convenient perusal of the security audit trail. These tools must allow the selection of audit entries based on user, object, or event. _M_E_E_T_I_N_G _O_R_A_N_G_E _B_O_O_K _R_E_Q_U_I_R_E_M_E_N_T_S The most obvious goal for the Multics security audit trail is that the mechanisms and facilities meet the requirements for a B2 level system as defined by the DoD Trusted Computer System Evaluation Criteria (known as the "Orange Book") [CSC-STD-001-83 15 August 1983]. The applicable paragraph (3.2.2.2) states: "The TCB shall be able to create, maintain, and protect from modification or unauthorized access or destruction an audit trail of accesses to the objects it protects. The audit data shall be protected by the TCB so that read access to it is limited to those who are authorized for audit data. The TCB shall be able to record the following types of events: use of 2-1 MDD-029 Security Auditing identification and authentication mechanisms, introduction of objects into a user's address space (e.g. file open, program initiation), deletion of objects, and actions taken by computer operators and system administrators and/or system security officers. The TCB shall also be able to audit any override of human-readable output markings. For each recorded event, the audit record shall identify: date and time of the event, user, type of event, and success or failure of the event. For identification/authentication events the origin of request (e.g., terminal ID) shall be included in the audit record. For events that introduce an object into a user's address space and for object deletion events the audit record shall include the name of the object and the object's security level. The ADP system administrator shall be able to selectively audit the actions of any one or more users based on individual identity and/or object security level. The TCB shall be able to audit the identified events that may be used in the exploitation of covert storage channels." Sections 5.3.2 and 7.4 of the Orange Book provide further information about the types of events that are to be audited. 2-2 Security Auditing MDD-029 SECTION 3 OVERVIEW This section describes, in general, the design of the system auditing mechanisms. _U_S_E _O_F _S_Y_S_T_E_M _L_O_G_S Security audit trail entries appear as messages in the system logs. All standard security audit messages will exhibit the "access_audit" data class. There are some non-standard audit messages (see AK50 for complete details). _A_U_D_I_T _M_O_D_U_L_E_S There are a small number of modules which are called upon to perform the actual generation of audit messages. The caller must supply a description about the operation being performed (see next section), the name of the object involved, whether the operation is performed under privileges, etc. A standard audit message text and binary data will be formed from this information and the process identity. It will then be placed into the appropriate log. The audit modules may also make a decision about whether to suppress generation of an audit message. This decision depends upon the operation, the object, and some audit selectivity criteria set up by the system security administrator. _O_P_E_R_A_T_I_O_N _D_E_S_C_R_I_P_T_I_O_N This section describes the information which must be supplied to the audit modules. 3-1 MDD-029 Security Auditing _O_b_j_e_c_t _N_a_m_e The name of the object is necessary for entry into the audit message. In the case of file system objects, it is the object's pathname. The audit module may derive the name from a supplied pointer. For RCP objects, it is the device or volume name. _O_b_j_e_c_t _A_c_c_e_s_s _C_l_a_s_s The object access class is compared to the system audit thresholds to determine whether auditing is required. It is also entered into the audit message. For some objects, such as file system objects, the audit module can derive this information from the object name. _O_p_e_r_a_t_i_o_n _C_o_d_e The "access_operations_" table contains an entry for every TCB operation which may be audited. Audit module callers must supply the value of one of these entries. Encoded in the value are: The class of the object involved. The type of operation. A unique operation index. The following paragraphs describe each of these components. OBJECT CLASS May be one of the following: fsobj - File System Object. This includes segments, directories, and links. Multi-segment files are not TCB controlled objects. fsattr - File System Attribute. This is the attributes associated with file system objects. They include object access properties, status properties, etc. Note that all other object classes implicitly include their own attributes. File system objects and attributes were separated into two classes for finer granularity in audit selectivity. rcp - RCP Object. Is a device or volume controlled by RCP. It may be a tape reel, a disk drive, a console, etc. admin - Administrative Object. Is a file used for administrative purposes such as the PNT. special - Special Object. Is an object that has special characteristics such as a process. Currently, only Initializer manipulations of processes, and wakeup signals are considered to be operations on processes. 3-2 Security Auditing MDD-029 other - Other Object. Is an object not covered in the above classes. For instance, messages (as inside of mailboxes) are considered in this class. OPERATION TYPE These are classes of operations on objects. There are only three: MODIFY_ACCESS - specifies that the operation modifies the access attributes (ACL, rings, or AIM) of the object. MODIFY - specifies that the operation modifies the contents or the non-access attributes of the object. READ - specifies that the operation reads the contents or the attributes of the object. UNIQUE INDEX The unique index of the operation is just that. All TCB defined operations are placed in a table. Each entry is assigned its own table index as its unique index. This index will never change for a given operation. _O_p_e_r_a_t_i_o_n _S_t_a_t_u_s The caller of the audit module must specify whether the access attempt (or the operation) was successful or unsuccessful. _O_p_e_r_a_t_i_o_n _M_o_d_e The caller of the audit module must specify any modes under which the operation was performed/attempted. One of the following may be set. If none are, a normal user operation is indicated. special_op - an operation which is of sufficient interest to always be audited, regardless of process or system audit flags. admin_op - an operation which is defined as system administrative, or performed via an administrative interface. priv_op - an operation performed via a privileged interface or under the appropriate AIM privilege. small_cc - an operation which may be used to exploit a small (1-10 bps) covert channel. (Covert channels smaller than 1bps are considered trivial and not necessary to audit. All covert channels are documented, however). moderate_cc - an operation which may be used to exploit a moderate (10-100 bps) covert channel. (Covert channels 3-3 MDD-029 Security Auditing larger than 100bps are considered security holes and cannot exist in a B2 system. They are either reduced in size or completely closed). receiver - indicates whether the process is on the receiver side of the covert channel. _A_U_D_I_T _T_R_A_I_L _S_E_L_E_C_T_I_V_I_T_Y Selection of audit trail entries can occur at two times. The security administrator can reduce the entries presented through use of the log perusal tools. These have controls to select messages for display. The security administrator can also set up a filter which reduces the audit trail entries that are actually logged. Uninteresting entries can be discarded automatically even before they consume space in the logs. The two filtering mechanisms are described in the following paragraphs. _S_y_s_t_e_m _A_u_d_i_t _F_l_a_g_s _a_n_d _T_h_r_e_s_h_o_l_d_s There are three system auditing flags to control auditing of successful and unsuccessful access attempts and potential use of covert channels. If a flag is off, auditing of the associated class of operations is always suppressed. Each of the system audit flags is paired with an access class value. This access class is interpreted as a threshold for auditing. For successful and unsuccessful access auditing, the threshold is compared with the access class of the object involved in the operation (e.g. the segment being initiated). If the segment's access class is lower than the threshold, auditing of the operation is suppressed. For covert channel operations, auditing on the sender side of the channel is suppressed if the process' authorization is lower than the threshold. The threshold does not affect auditing if the process is on the receiver side of the channel (since it's not possible to determine the authorization of the sender side). It is preferable to audit covert channels on the sender side wherever possible. Comparison of the object access class (or process authorization) with the system threshold is NOT performed by aim_check_. A dominance relationship is not of interest. Instead, the aim level and categories are compared separately, according to the following: 3-4 Security Auditing MDD-029 if obj_access_class.level >= threshold.level | (obj_access_class.categories & threshold.categories) then audit_the_event This states that if the object's (process') aim level is greater than the aim level of the threshold, auditing should occur. Independently, if the object (process) has any aim categories in common with those of the threshold, auditing should occur. Thus, a system security administrator could setup auditing to occur above a specified level, or for specified compartments (categories) regardless of level. The system audit flags and thresholds are settable via the set_system_audit_flags command. _P_e_r_-_P_r_o_c_e_s_s _A_u_d_i_t _C_o_n_t_r_o_l On a per-process basis, the system security administrator can setup auditing of the use of objects within certain classes. Also, auditing can be setup for certain operation modes, regardless of the object involved. Auditing prescribed by the process audit flags may be suppressed by the system audit flags/thresholds. The following two sections describe the process audit control levels and flags. The system administrator sets up audit control flags for users (in the PNT entries) and projects (in the SAT entries) via the new_user and new_proj commands respectively. Defaults are drawn from sys_admin_data which may be set using the admin_util command. The flags for existing users and projects may be modified using the new_user$c* or the edit_proj commands respectively. These two sets of flags are combined, at process creation time, by the answering service. The combination is performed so as to yield the greatest amount of auditing. Changes to these flags do not affect running processes. | _P_e_r_-_O_b_j_e_c_t _A_u_d_i_t _C_o_n_t_r_o_l | A file system object audit flag (known as the "audit switch") is | associated with each entry in the file system. The setting of | this switch can only be modified by the system security | administrator. If this switch is on, then all accesses of the | segment, either successful or unsuccessful, are audited. In the | case of mailboxes and message segments, audit messages are | produced for segment-level accesses (e.g., opening, deleting, | reading or changing ACLs, reading or changing attributes) but not | for message-level accesses (adding, deleting, reading, or | updating messages). | 3-5 MDD-029 Security Auditing OBJECT AUDIT LEVELS As described above, there are six classes defined for object controlled by the Multics TCB. For each class, the system security administrator may define a pair of auditing levels. The first defines the level of auditing for successful object access attempts, the second defines the level of auditing for unsuccessful object access attempts. The levels may be one of the following: N - (none) No auditing need be done MA - (modify-access) Audit operations which modify object access attributes M - (modify) Audit operations which modify the object or any of its attributes R - (read) Audit operations which read or write the object or any of its attributes The read ("R") level of auditing causes the greatest number of messages to be generated. The audit levels for objects are specified in pairs. The following illustrates (in the textual representation) a possible audit level setting for a user or project: fsobj=M/R,fsattr=MA/R,rcp=R/R,admin=R/R,special=R/R,other=M/R The level pairs following each equal sign (=) represent the successful and unsuccessful access audit levels respectively. For instance, all successful attempts to modify a file system object will be audited. All unsuccessful attempts to read or modify a file system object will be audited. (Note that since file system attributes are considered separate objects, the "MA" level for "fsobj" is invalid). During process creation object auditing levels from the user's PNT entry and the project's SAT entry are combined. For each level value, the larger of the two is used. OPERATION MODE AUDITING The security administrator may wish to audit certain operations based on the mode of the operation (see "Operation Modes" above), regardless of the auditing level of the object involved. There are 5 flags which control auditing for certain modes of operations. Four of these correspond to operations modes (special_op and receiver are not included). There is an extra flag which controls the auditing of faults. A string of process audit flags may appear as: 3-6 Security Auditing MDD-029 priv_op,admin_op,^faults,^small_cc,moderate_cc During process creation audit flags from the user's PNT entry and the project's SAT entry are combined. They are simply "or'd" together. _A_L_G_O_R_I_T_H_M _F_O_R _D_E_T_E_R_M_I_N_I_N_G _W_H_E_T_H_E_R _T_O _A_U_D_I_T The audit modules access_audit_, access_audit_check_ep_, and access_audit_log_fault_ must determine whether auditing is required for a given operation. Auditing of faults is dependant only on the state of the "faults" flag in the process audit control flags (actually checked in the program "fim"). System auditing thresholds have no impact on fault auditing. The basic algorithm for the other two is: IF object audit flag is on | THEN RETURN (audit_the_event) | IF operation mode is a small/moderate covert channel THEN IF covert channel system audit flag is on THEN IF process above covert channel auditing threshold | operation mode is receiver THEN IF process audit flag small_cc/moderate_cc on THEN RETURN (audit_the_event) IF operation mode is administrative operation THEN IF process audit flag admin_op on THEN RETURN (audit_the_event) IF operation mode is privileged operation THEN IF process audit flag priv_op on THEN RETURN (audit_the_event) IF operation state is successful access THEN IF successful access system audit flag is off THEN RETURN (dont_audit) ELSE IF object access class not above successful access threshold THEN RETURN (dont_audit) IF operation state is unsuccessful access THEN IF unsuccessful access system audit flag is off THEN RETURN (dont_audit) ELSE IF object access class not above unsuccessful access threshold THEN RETURN (dont_audit) get object auditing level from process audit flags (N, MA, M, or R) 3-7 MDD-029 Security Auditing get operation type (modify_access, modify, or read) IF auditing level = R & operation type = read | operation type = modify | operation type = modify_access) THEN RETURN (audit_the_event) IF auditing level = M & (operation type = modify | operation type = modify_access) THEN RETURN (audit_the_event) IF auditing level = MA & operation type = modify_access THEN RETURN (audit_the_event) IF auditing level = N THEN RETURN (dont_audit) _M_A_J_O_R _P_R_O_G_R_A_M_M_A_T_I_C _I_N_T_E_R_F_A_C_E_S This section briefly describes the major interfaces which perform security auditing. For a more detailed discussion see the following section "Implementation". _a_c_c_e_s_s___a_u_d_i_t__ The access_audit_ module is the major component involved in security auditing. It is callable in ring 0 (and through the two gates described in the succeeding sections). There are two major sets of entrypoints. The first set of entrypoints all start with the characters "log_" followed by a description of what object identification is supplied by the caller. For instance, the caller of access_audit_$log_entry_ptr provides a directory entry pointer to the storage system entry involved in the auditable event. The caller must also supply an operation description as outlined in the preceding sections. The second set of entrypoints all start with the characters "check_" followed, as for the log_ entrypoints, by a description of what object identification is supplied. These entrypoints perform only the determination of whether auditing of the event is necessary. No log message is generated. A TCB module may avoid costly audit setup if the event is not to be audited. 3-8 Security Auditing MDD-029 _a_c_c_e_s_s___a_u_d_i_t___r_1__ This is a transfer vector for ring 1 TCB modules which need to perform auditing. It has entries parallel to all the useful access_audit_ entries (entries such as $log_entry_ptr are not useful outside ring 0). Each entry transfers to admin_gate_ to perform the actual inner ring call. _a_c_c_e_s_s___a_u_d_i_t___g_a_t_e__ This is a gate for user ring modules which need to perform auditing (e.g. IO daemons). It has entries which parallel all the useful access_audit_ entrypoints. _a_s___a_c_c_e_s_s___a_u_d_i_t__ The as_access_audit_ module provides the major interfaces for auditing by the Multics answering service. It places all its audit entries into the answering service log. _C_O_M_M_A_N_D _I_N_T_E_R_F_A_C_E_S This section briefly describes the command interfaces to the security audit trail. For more detailed information, consult the published documentation. _(_n_e_w___u_s_e_r _n_e_w___p_r_o_j _e_d_i_t___p_r_o_j _a_d_m_i_n___u_t_i_l_) These commands provide facilities to setup and modify process audit flags in the user's PNT entry and the project's SAT entry. _(_d_i_s_p_l_a_y _s_e_t _e_d_i_t_)___p_r_o_c_e_s_s___a_u_d_i_t___f_l_a_g_s These commands manipulate the process's own audit flags. It is a highly privileged operation meant only for experimentation by the system security administrator. _(_d_i_s_p_l_a_y _s_e_t_)___s_y_s_t_e_m___a_u_d_i_t___f_l_a_g_s These commands manipulate the system auditing flags and thresholds. It is a highly privileged operation meant for use in the system startup exec com or during normal operation by the system security administrator. 3-9 MDD-029 Security Auditing _(_p_r_i_n_t _s_u_m_m_a_r_i_z_e _m_o_n_i_t_o_r_)___s_y_s___l_o_g These commands allow perusal of the security audit trail. 3-10 Security Auditing MDD-029 SECTION 4 IMPLEMENTATION This section describes the actual data structures, variables, and modules that comprise the security auditing facility. _D_A_T_A _S_T_R_U_C_T_U_R_E_S The following paragraphs describe the content of include file associated with system security auditing. _a_c_c_e_s_s___a_u_d_i_t___e_n_c_o_d_e_d___o_p_._i_n_c_l_._p_l_1 This include file defines the format of data which describes the operation. All entries in the access_operation_ table are of this format. /* as of MR11 (5/85), no journalization */ dcl 1 encoded_access_op aligned based, 2 audit_type unaligned, 3 object_type fixed bin (4) uns unal, 3 access_type fixed bin (2) uns unal, 2 operation_index fixed bin (12) uns unal, 2 detailed_operation fixed bin (18) uns unal; where: object_type is the class of the object involved in the operation. It may be File_System_Object, File_System_Attribute, Administrative_Object, Special_Object, or Other_Object. A value of zero implies that no object was involved in the operation (e.g. setting of privileges). access_type is the mode of access to the object. It may be Modify_Access, Modify, or Read. A value of zero implies 4-1 MDD-029 Security Auditing that no access to an object was involved (e.g identification and authentication of a user). operation_index is the index of this code in access_operations_. detailed_operation is additional info inserted by the caller of the auditing module. For instance, file system and RCP operations place an encoded value in this field which represents the precise operation performed (see fs_obj_access_codes.incl.pl1 and rcp_ops.incl.pl1). _a_c_c_e_s_s___a_u_d_i_t___e_v_e_n_t_f_l_a_g_s_._i_n_c_l_._p_l_1 This include file describes a set of flags which is passed to the auditing module access_audit_. It contains the operation status (successful/ unsuccessful) and the operation mode. /* as of MR11 (5/85), no journalization */ dcl 1 audit_event_flags based aligned, 2 special_op bit (1) unal, 2 grant bit (1) unal, 2 admin_op bit (1) unal, 2 priv_op bit (1) unal, 2 cc_1_10 bit (1) unal, 2 cc_10_100 bit (1) unal, 2 receiver bit (1) unal, 2 pad bit (29) unal; where: special_op indicates whether the operation is to be always audited (e.g. setting AIM privileges). grant indicates whether the access was granted (successful). admin_op indicates that the operation is accessed via an administrative interface. priv_op indicates that the operation is accessed via a privileged interface. cc_1_10 indicates that the operation can be utilized to exploit a small covert channel (1-10 bits per second). 4-2 Security Auditing MDD-029 cc_10_100 indicates that the operation can be utilized to exploit a moderate covert channel (10-100 bits per second). receiver indicates, if one of the covert channel indicators is on, that the operation is performed on the receiving side of the channel. _a_c_c_e_s_s___a_u_d_i_t___u_s_e_r___i_n_f_o_._i_n_c_l_._p_l_1 This include file defines the data which is passed to access_audit_ "user" entries. These entries are called upon by privileged processes which perform some function on behalf of another user (e.g. IO daemon, Initializer). User identification and access attributes are supplied by the message segment primitives (which are used to implement operation request mechanisms). /* 85-01-21 EJ Sharpe - Last Modified */ dcl 1 audit_user_info based (audit_user_info_ptr) aligned, 2 version char (8), 2 user_id char (32), 2 ring fixed bin (3) uns unal, 2 pad bit (33) unal, 2 process_id bit (36) aligned, 2 authorization bit (72) aligned, 2 authorization_range (2) bit (72) aligned, 2 audit_flags bit (36) aligned; where: version is a structure identification string. user_id is the person.project.tag of the requesting process. ring is the validation level of the requesting process at the time of the request. process_id is the unique process ID of the requesting process. authorization is the AIM authorization of the requesting process. 4-3 MDD-029 Security Auditing authorization_range is the minimum and maximum AIM authorization at which the user may log in. audit_flags are the security audit control flags of the requesting process. _a_c_c_e_s_s___a_u_d_i_t___f_l_a_g_s_._i_n_c_l_._p_l_1 This include file defines the format of the process security audit control flags. It appears in the same format in pds$audit_flags, in sys_admin_data, in the user's PNT entry, and in the project's SAT entry. /* 85-01-14 EJ Sharpe - Last Modified */ dcl 1 audit_flags based aligned, 2 objects (6) unal, /* n_audit_objects */ 3 grant_level fixed bin (2) uns unal, 3 deny_level fixed bin (2) uns unal, 2 pad bit (7) unal, 2 admin_ops bit (1) unal, 2 priv_ops bit (1) unal, 2 faults bit (1) unal, 2 cc_1_10 bit (1) unal, 2 cc_10_100 bit (1) unal; dcl 1 audit_flags_alt based aligned, 2 objects (6) unal, /* n_audit_objects */ 3 grant_level fixed bin (2) uns unal, 3 deny_level fixed bin (2) uns unal, 2 pad bit (7) unal, 2 flags (5) bit (1) unal /* n_audit_flags */; dcl n_audit_objects init (6) fixed bin int static options (constant); dcl n_audit_flags init (5) fixed bin int static options (constant); dcl n_audit_access_types init (3) fixed bin int static options (constant); dcl ( FSOBJ_AUDIT_OBJECT_INDEX init (1), FSATTR_AUDIT_OBJECT_INDEX init (2), RCP_AUDIT_OBJECT_INDEX init (3), ADMIN_AUDIT_OBJECT_INDEX init (4), SPECIAL_AUDIT_OBJECT_INDEX init (5), OTHER_AUDIT_OBJECT_INDEX init (6) ) fixed bin int static options (constant); 4-4 Security Auditing MDD-029 dcl ( ADMIN_OP_AUDIT_FLAG_INDEX init (1), PRIV_OP_AUDIT_FLAG_INDEX init (2), FAULTS_AUDIT_FLAG_INDEX init (3), CC_1_10_AUDIT_FLAG_INDEX init (4), CC_10_100_AUDIT_FLAG_INDEX init (5) ) fixed bin int static options (constant); dcl ( NONE init (0), MODIFY_ACCESS init (1), MODIFY init (2), READ init (3) ) fixed bin (2) uns int static options (constant); where: objects is an array of audit level pairs ("grant_level" and "deny_level"). These audit levels control, for successful and unsuccessful access attempts respectively, which operation types are to be audited. There are four possibilities: No_Auditing, Modify_Access, Modify, and Read. admin_ops is a flag which indicates whether operations which have the "admin_op" operation mode (see access_audit_eventflags.incl.pl1) are to be audited. (Note that the operation may be audited even if this flag is off, dependant upon auditing level for the object involved). priv_op is a flag which indicates whether operations which have the "priv_op" operation mode (see access_audit_eventflags.incl.pl1) are to be audited. (Note that the operation may be audited even if this flag is off, dependant upon auditing level for the object involved). faults is a flags indicating whether access violation and illegal procedure faults are to be audited. cc_1_10 is a flag which indicates whether operations which have the "cc_1_10" operation mode (see access_audit_eventflags.incl.pl1) are to be audited. (Note that the operation may be audited even if this flag is off, dependant upon auditing level for the object involved). cc_10_100 is a flag which indicates whether operations which have the 4-5 MDD-029 Security Auditing "cc_10_100" operation mode (see access_audit_eventflags.incl.pl1) are to be audited. (Note that the operation may be audited even if this flag is off, dependant upon auditing level for the object involved). audit_flags_alt is an alternative declaration for the audit_flags structure. It allows the individual operation mode audit flags to be referenced by an index. _a_c_c_e_s_s___a_u_d_i_t___n_a_m_e_s_._i_n_c_l_._p_l_1 is an include file that contains arrays of string constants used in converting audit flag and event structures to textual representations and back to the binary structure. It is used by access_audit_ in formatting the audit message text, by access_audit_util_ in formatting metering data, and by convert_access_audit_flags_ for flag conversion. _a_c_c_e_s_s___a_u_d_i_t___b_i_n___h_e_a_d_e_r_._i_n_c_l_._p_l_1 This include file defines the structure of the first section of the binary data associated with each standard audit message. /* 85-01-18 E. Swenson - Last Modified */ dcl 1 audit_record_header aligned based (audit_record_ptr), 2 header aligned like arh_header_, 2 subject aligned like arh_user_info_; dcl 1 audit_record_header_proxy aligned based (audit_record_ptr), 2 header aligned like arh_header_, 2 subjects (2) aligned like arh_user_info_; dcl 1 arh_header_ aligned based, 2 type fixed bin (9) unsigned unaligned, 2 version fixed bin (9) unsigned unaligned, 2 flags unaligned, 3 ( subject_is_process, object_is_valid ) bit (1) unaligned, 3 pad bit (16) unaligned, 2 operation_code bit (36) aligned, 2 event_flags bit (36) aligned, 2 session_uid fixed bin (35); 4-6 Security Auditing MDD-029 dcl 1 arh_user_info_ aligned based, 2 person char (22) unaligned, 2 project char (9) unaligned, 2 tag char (1) unaligned, 2 ring fixed bin (3) uns unaligned, 2 anonymous bit (1) unaligned, 2 pad3 bit (32) unaligned, 2 process_id bit (36) aligned, 2 authorization bit (72) aligned, 2 authorization_range (2) bit (72) aligned; dcl ARH_TYPE_PROXY fixed bin init (2) static options (constant); dcl ARH_TYPE_NO_PROXY fixed bin init (1) static options (constant); dcl ACCESS_AUDIT_HEADER_VERSION_3 fixed bin (9) unsigned init (3) static options (constant); where: audit_record_header This structure is used when the operation being audited is performed for and by the process itself. It exhibits a single instance of the "subject" substructure. audit_record_header_proxy This structure is used when the process which performed the operation did so on the behalf of another process. The process which actually performed the operation is a "proxy". Requests from other processes typically come to the proxy via a message segment (e.g. IO request queues). There are two instances of the "subject" substructure. The first identifies and lists access attributes of the proxy. The audit module fills in this information from data available in ring 0. The second structure instance is filled in from data supplied by the proxy. It is found in the request message header and passed to the audit module via the structure defined in access_audit_user_info.incl.pl1. type Defines the type if this audit record header. It is either ARH_TYPE_PROXY or ARH_TYPE_NO_PROXY. Incidentally it defines the extent of the "subject" array. version Is a structure version identifier. subject_is_process Indicates that "subject(1)" is the actual process for which the operation was performed (i.e. not a proxy). 4-7 MDD-029 Security Auditing object_is_valid Indicates that there is additional binary information appearing after the audit record header in the log message. This flag is not really useful since the fact can be easily determined from the length of the log message binary data. operation_code Is the encoded operation description (see access_audit_encoded_op.incl.pl1). event_flags Is a word of event flags associated with the operation (see access_audit_eventflags.incl.pl1). session_uid Appears in audit messages generated by the identification and authentication mechanisms of the answering service. It is the unique terminal session ID which does not change across new_procs, etc. until the terminal line is dropped. (Currently the session_uid gets set back to the original value upon process reconnection - this should be fixed). arh_user_info_ Is the process identification and access attributes of the proxy and/or user who performed the operation. It contains the same information as defined in access_audit_user_info.incl.pl1. _a_c_c_e_s_s___a_u_d_i_t___b_i_n_a_r_y___d_e_f_._i_n_c_l_._p_l_1 This include file defines constants for the codes which identify the format of extended binary data (which follows the audit record header structure. The code is in the first 9-bit byte of the data. See the following include files for the format of the extended binary data.: as_audit_structures.incl.pl1 access_audit_mseg.incl.pl1 access_audit_rcp.incl.pl1 access_audit_ssobj.incl.pl1 pnt_audit_record.incl.pl1 _a_c_c_e_s_s___a_u_d_i_t___m_e_t_e_r___i_n_f_o_._i_n_c_l_._p_l_1 This include file defines a structure in which meters are copied from ring-0 to the user ring. There is no installed user-ring program for printing the meters. 4-8 Security Auditing MDD-029 /* no journalization - MR11 version approx May 1985 */ dcl 1 audit_meter_info based (audit_meter_info_ptr) aligned, 2 version char (8), 2 meters (audit_meter_info_num), 3 name char (32), 3 cpu_time fixed bin (71), 3 pagefaults fixed bin (71), 3 count fixed bin (35), 3 check_count fixed bin (35); where: version Is a structure identifier. meters Is an array of meters. Each element corresponds to one "row" of the meters in active_hardcore_data (see "System Constants and Variables" below). name Is the name of the meter which defines the category of events audited. For object access meters, this will include the object class, the metered access type (modify access, modify, or read), and whether the meter is for successful or unsuccessful object accesses. For event oriented meters, it will be the name of the associated event. cpu_time Is the virtual CPU time consumed by the audit module while performing the audit for this category. pagefaults Are the number of page faults taken by the audit module while performing the audit for this category. count Is the number of calls to the audit module for this category. check_count Is the number of calls to the audit module for this category where the only task is to determine if auditing is necessary, not actually to generate an audit message. _M_E_S_S_A_G_E _T_E_X_T _F_O_R_M_A_T Audit trail entries exhibit a standardized format for the log message text. It is well documented in the Multics System Administration Procedures manual order no. AK50. 4-9 MDD-029 Security Auditing _S_Y_S_T_E_M _C_O_N_S_T_A_N_T_S _A_N_D _V_A_R_I_A_B_L_E_S The following paragraphs describe various system variables which are set and/or referenced in the course of generating audit trail entries. _a_c_c_e_s_s___o_p_e_r_a_t_i_o_n_s___._a_l_m This table contains an entry for each operation defined by the TCB. It is assembled and placed on the system hardcore tape. It is not changed except as necessary as TCB operations are modified. The following diagram illustrates the internal format of this table. Each name shown is the name of a special entrypoint. ----------------------- | version (2 words) | ----------------------- | num_codes | ----------------------- | | code_table | | ----------------------- | | text_offset_table | | ----------------------- | | text_area | | ----------------------- where: access_operations_$version is a structure identifier. access_operations_$num_codes indicates the number of entries in the table. This is the same for the "code_table" and "text_offset_table". access_operations_$code_table is an array of encoded values which define all operations supported by the TCB. Each value is a full word whose internal format is described by the include file access_audit_encoded_op.incl.pl1. Note that the "operation_index" of the encoded value is simply the index of the value in the "code_table" array. Each value is also accessible by a unique entrypoint. 4-10 Security Auditing MDD-029 Some examples are: access_operations_$fs_obj_initiate access_operations_$rcp_register access_operations_$user_logout A referencing program must declare these entrypoints as "bit (36) aligned external". They are then passed to the audit modules to identify the operation being performed. access_operations_$text_offset_table is an array of offsets and lengths. Each element corresponds to an element in the "code_table" array. The offset points to a character string which corresponds to the TCB operation. The length is the number of characters in the string. Thus, the "operation_index" of an encoded operation value, when used to index into this table, will yield an offset and a length. That offset points to the textual description of the operation. access_operations_$text_area provides storage for the textual descriptions corresponding to all the "code_table" entries. _s_y_s___i_n_f_o The sys_info data segment contains constants and variables for many parts of the system. The following are related to security auditing. All these values may be set via the "set_system_audit_flags" command. sys_info$audit_successful_access sys_info$audit_unsuccessful_access sys_info$audit_covert_channel are indicators which control the auditing of the associated types of operations. If they are all off, no audit trail entries will be generated except for those operations which are flagged as "special_ops" in the operation event flags (see access_audit_eventflags.incl.pl1). sys_info$successful_access_threshold sys_info$unsuccessful_access_thresold sys_info$covert_channel_threshold are thresholds which control auditing of the associated types of operations. They are referenced only when the corresponding indicator (described in the previous paragraph) is on. For successful and unsuccessful operation attempts, the audit trail entry is supressed if the access class of the object involved is lower than the threshold 4-11 MDD-029 Security Auditing (unless the "admin_op" or "priv_op" indicators are on in the operation event flags and the user process audit flags). For covert channel operations, the audit trail entry is suppressed if the access class of the process is lower than the threshold (unless the "receiver" event flag is on). See the section "Algorithm for Determining Whether to Audit" for complete details on the interaction of event flags, process audit flags, system audit flags, and these audit thresholds. _p_d_s_$_a_u_d_i_t___f_l_a_g_s This holds the per-process audit control flags described in the include file access_audit_flags.incl.pl1. It is set by the answering service at process creation time and never changed (except by highly privileged operations). It is a combination of the values of sat.project.audit and pnt_entry.audit. _s_a_t_._p_r_o_j_e_c_t_(_N_)_._a_u_d_i_t This is the default set of per-process audit control flags for the associated project. It may be set by the new_proj and edit_proj commands. The answering service combines this with the value of pnt_entry.audit to produce the flags used for the process. _p_n_t___e_n_t_r_y_._a_u_d_i_t This is the default set of per-process audit control flags for the associated user. It may be set by the new_user command. The answering service combines this with the value of sat.project.audit to produce the flags used for the process. _s_y_s___a_d_m_i_n___d_a_t_a_._d_e_f_a_u_l_t___a_u_d_i_t___f_l_a_g_s This is an initial set of per-process audit control flags for new projects or users as they are registered. It may be set with the admin_util command. _p_d_s_$_n_o___a_u_d_i_t___r_i_n_g_1___f_s___o_b_j_e_c_t___o_p_s This is a flag which indicates that auditing is to be suppressed for ring 1 objects. It is set only by level$set_admin_gate (referenced only by admin_gate_$admin_level_no_fs_audit) when the process's initial ring is greater than 1 and the flag active_hardcore_data$audit_ring1_fs_object_ops is off. This 4-12 Security Auditing MDD-029 reduces the amount of duplicated auditing for such operations as mailbox openings which are already audited in ring 1 (without this suppression mechanism, for example, dc_find would generate another audit for the mailbox segment initiation). _a_c_t_i_v_e___h_a_r_d_c_o_r_e___d_a_t_a_$_a_u_d_i_t___r_i_n_g_1___f_s___o_b_j_e_c_t___o_p_s This indicates that pds$no_audit_ring1_fs_object_ops is never to be turned on. Thus, ring 1 TCB operations cannot suppress ring 0 file system auditing duplication. There is no interface to turn this flag on, it is meant for debugging purposes. However, a security administrator who wishes to generate the duplicate auditing can turn this on via patch_ring_zero or by recompiling active_hardcore_data.cds (and generating a new MST). _a_c_t_i_v_e___h_a_r_d_c_o_r_e___d_a_t_a _- _M_e_t_e_r_i_n_g _D_a_t_a This data segment contains variables and constants for many parts of the system. There are four entrypoints used by the auditing modules to keep track of resources used. They are: active_hardcore_data$access_audit_num_meters active_hardcore_data$access_audit_count active_hardcore_data$access_audit_cpu_time active_hardcore_data$access_audit_pagefaults active_hardcore_data$access_audit_check_count The first entrypoint (access_audit_num_meters) defines the number of meter buckets. The rest are arrays of values. The corresponding elements of each of these arrays, when taken together, form a metering "bucket". The meters for auditing of object access can be viewed as a matrix of buckets which looks like: buckets (n_object_classes, n_access_types, n_status_values) where n_object_classes is six (fsobj, fsattr, rcp, admin, special, other), n_access_types is three (modify_access, modify, read), and n_status_values is two (successful, unsuccessful). Thus, at present, the first 36 buckets in the linear arrays (as defined) are used to meter auditing related to TCB objects. For each of the event flags (admin_op, priv_op, small_cc, moderate_cc, fault) there is a meter bucket kept. Thus, at present, buckets 37 through 41 are used to meter auditing related to TCB events. Additionally, there is an extra meter bucket for events not covered above. This should always be zero unless there is an 4-13 MDD-029 Security Auditing error in the number of meter buckets allocated or an error in the TCB auditing mechanism. Thus, at present, this is meter bucket 42. This data structure is pretty silly. What really should have been implemented is the following: access_audit_num_object_meters constant init (6); access_audit_object_meters (6, 2) like access_audit_meter_bucket_; access_audit_num_event_meters constant init (5) access_audit_event_meters (5) like access_audit_meter_bucket_; access_audit_extra_meters (1) like access_audit_meter_bucket_; dcl 1 access_audit_meter_bucket_ aligned based, 2 vcpu fixed bin (71), 2 pagefaults fixed bin (35), 2 count fixed bin (35), 2 check_count fixed bin (35), 2 pad fixed bin (35); This data structure for the meter buckets would have simplified the code and this documentation. It should be evaluated for future implementation. _M_O_D_U_L_E_S The following paragraphs describe each module in detail. _a_c_c_e_s_s___a_u_d_i_t___._p_l_1 This module resides in bound_system_security in hardcore. It is central to the security auditing mechanism. For any auditable TCB operation performed within the user address space (ring 0 or ring 1) a call to access_audit_ is made. First, a determination is made as to whether auditing is required. If so, a log message is formatted and entered into the syserr log. The following entrypoints are available: log_general log_general_user log_obj_class log_obj_class_user log_obj_class_range log_obj_class_range_user 4-14 Security Auditing MDD-029 log_obj_path log_obj_path_user log_obj_ptr log_obj_ptr_user log_entry_ptr log_entry_ptr_user log_no_process check_general check_general_user check_obj_class check_obj_class_user check_obj_class_range check_obj_class_range_user check_obj_path check_obj_path_user check_obj_ptr check_obj_ptr_user The log_* entries perform the determination of whether an audit entry should be generated, and, if so, enters a message in the log. The check_* entries do not enter a message, they just return a flag to the caller indicating whether generation of an audit message is necessary. The *_user entries are called by privileged proxy processes when performing an operation on behalf of another user. They accept, in addition to the usual arguments, a structure of user information (see access_audit_user_info.incl.pl1). access_audit_ will use this information, instead of the process information in ring 0, to determine whether auditing is necessary. The information will also appear in the audit message itself. The log_no_process entrypoint was intended for use by privileged processes which perform operations on the behalf of users who do not have their own process (e.g. the answering service). It is not currently used. The following pseudo-code illustrates the algorithm used by the logging entrypoints. The algorithm for determining whether auditing is required was given in section 3 "Overview". start meters copy args and setup if caller supplied object pointer or pathname then get directory entry pointer if auditing is required then do if object is in storage system then build extended binary data 4-15 MDD-029 Security Auditing if text info provided by caller then format any optional args format standard message text (include caller supplied text) build binary data header create a log entry including the text info, the binary data header, the extended binary data we built, and any caller supplied binary data end stop meters return Appendix A has complete documentation of all the access_audit_ entrypoints. _a_c_c_e_s_s___a_u_d_i_t___r_1___._a_l_m This transfer vector resides in bound_library_3_ in hardcore. It has entrypoints identical to those of access_audit_ and access_audit_util_ (except those that are directory entry pointer oriented). It uses entrypoints in admin_gate_ to invoke these modules in ring 0. However, ring 1 TCB modules are to use this transfer vector for auditing purposes. _a_c_c_e_s_s___a_u_d_i_t___g_a_t_e___._a_l_m This hardcore gate has entrypoints identical to those of access_audit_ and access_audit_util_ (except those that are directory entry pointer oriented). (It also does not have a "set_audit_flags" entrypoint - that is available only in hphcs_.) Ring 4 TCB modules are to use this gate for auditing purposes. _a_c_c_e_s_s___a_u_d_i_t___c_h_e_c_k___e_p___._a_l_m This module resides in bound_system_security in hardcore. It is an assembly language implementation of the algorithm which determines whether auditing of an operation is necessary. It is used by ring 0 file system modules to make an efficient determination before actually calling the access_audit_ module. 4-16 Security Auditing MDD-029 _a_c_c_e_s_s___a_u_d_i_t___l_o_g___f_a_u_l_t___._p_l_1 This module resides in bound_system_security in hardcore. It is called upon by fim.alm to enter an audit message about illegal procedure and access violation faults taken by the process. The determination of whether auditing is necessary is performed by fim.alm before access_audit_log_fault_ is called. _a_c_c_e_s_s___a_u_d_i_t___u_t_i_l___._p_l_1 This modules resides in bound_system_security in hardcore. It has entrypoints to get/set the per-process audit control flags and an entrypoint to fill in the access_audit_meters structure. _a_s___a_c_c_e_s_s___a_u_d_i_t___._p_l_1 This module resides in bound_as_misc_ in >tools. It is used by the answering service to audit process manipulation events. It has the following entrypoints: as_access_audit_$process Is called by cpg_, dpg_, and dialup_ to audit process creation, process destruction, process disconnects, and process reconnects. In all cases, the operation was successful if this entrypoint was called. (Note that the I&A audit messages about logins and logouts are generated by lg_ctl_). as_access_audit_$process_connect_denied Is called by dialup_ to audit unsuccessful attempts to reconnect to a process (e.g. new terminal access class incompatible). as_access_audit_$channel Is called by dial_ctl_ to audit all attempts to attach a communications channel to a process. An action code is supplied. If negative, the operation was denied. If positive, the operation was granted. as_access_audit_$dialid Is called by dial_ctl_ to audit all attempts to start/stop a dial service. An action code is supplied. If negative, the operation was denied. If positive, the operation was granted. (Note that audit messages about attempts to dial into the service are nonstandard messages ("DIALIN ") generated by dial_ctl_). 4-17 MDD-029 Security Auditing _s_e_t___s_y_s_t_e_m___a_u_d_i_t___f_l_a_g_s_._p_l_1 This command module resides in bound_security_tools_ in >tools. It implements the set_system_audit_flags and the display_system_audit_flags commands. _h_p_h_c_s__ _E_n_t_r_i_e_s This hardcore gate has two entries associated with access auditing. They are "set_sys_audit_thresholds" and "set_process_audit_flags" which are referenced by the set_system_audit_flags and set_process_audit_flags commands respectively. _s_e_t___s_y_s___a_u_d_i_t___t_h_r_e_s_h_o_l_d_s___._p_l_1 This module resides in bound_system_security in hardcore. It sets the system audit control flags and thresholds which reside in sys_info. It is accessible via the hphcs_ gate. _m_e_r_g_e___a_c_c_e_s_s___a_u_d_i_t___f_l_a_g_s___._p_l_1 This module resides in bound_security_tools_ in >tools. It is used to merge two sets of per-process audit control flags into a single set. The answering service uses this to combine the flags in the SAT and PNT when creating a process. _a_d_m_i_n___g_a_t_e___$_a_d_m_i_n___l_e_v_e_l___n_o___f_s___a_u_d_i_t This hardcore gate entrypoint is available to ring 1 TCB modules. It transfers to level$set_admin_gate which sets the pds$no_audit_ring1_fs_object_ops. This suppresses ring 0 auditing of file system operations on any ring 1 objects. The reason for this is that the ring 1 TCB modules are already generating audit message for these objects, there is no benefit in duplication by ring 0. Duplicate auditing may also cause confusion. The pds flag will be set only if the process's initial ring is grater than 1 and the "active_hardcore_data$audit_ring1_fs_object_ops" flag is off. _c_o_n_v_e_r_t___M_R_1_0___2___a_u_d_i_t___f_l_a_g_s___._p_l_1 This module resides in bound_admin_old_ in >tools. It is called by convert_MR10_2_sat_ and convert_v2_pnt_. Its purpose is to convert the pre-MR11 per-process audit flags format into the MR11 format. The two audit flag formats do not yield exactly the same 4-18 Security Auditing MDD-029 results. The conversion attempts to produce flags which will yield at least as much auditing as the old flags. _e_x_p_a_n_d___a_c_c_e_s_s___a_u_d_i_t___m_s_g___._p_l_1 This module resides in bound_log_tools_ in >tools. It is called by the logging subsystem module expand_log_message_ to convert the binary data of an access_audit data class message into a printable format. expand_access_aduit_msg_ will convert the binary header structure and call upon other expanders to handle any extended data (see next paragraph). _e_x_p_a_n_d___X_X_X_X_X___a_u_d_i_t___i_n_f_o___._p_l_1 These modules reside in bound_log_tools_ in >tools. They are called by expand_access_audit_msg_ to convert a piece of the extended binary data into a printable format. There is one expander for each type of extended data. Its name is generated from conversion tables found in access_audit_binary_defs.incl.pl1. _c_o_n_v_e_r_t___a_c_c_e_s_s___a_u_d_i_t___f_l_a_g_s___._p_l_1 This module resides in bound_security_tools_ in >tools. It is used to convert between text and binary representations of the per-process audit control flags. It has the following entrypoints: convert_access_audit_flags_$to_string Converts the bit string of flags into the standard textual representation. See AK50 description of new_user for examples. convert_access_audit_flags_$to_string_long Converts the bit string of flags into a long format suitable for printing. convert_access_audit_flags_$from_string Converts the standard audit flags text format into the bit string. convert_access_audit_flags_$edit_from_string Accepts a bit string of flags and a text string of flags. It changes the bit string only for those flags represented in the text string. All other flags remain unchanged. 4-19 MDD-029 Security Auditing _s_e_t___p_r_o_c_e_s_s___a_u_d_i_t___f_l_a_g_s_._p_l_1 This command module resides in bound_security_tools_ in >tools. It implements the set_process_audit_flags, display_process_audit_flags, and edit_process_audit_flags commands. _O_T_H_E_R _M_O_D_U_L_E_S _T_H_A_T _P_E_R_F_O_R_M _A_U_D_I_T_I_N_G This section describes some of the modules, otherwise unrelated to the security auditing mechanisms, which generate audit messages. _l_g___c_t_l___._p_l_1 This module resides in bound_user_ctl_ in >tools. It is part of the answering service. It generates standard audit trail message internally. It is the messages for I&A LOGIN and LOGOUT that are formatted by this module. _p_a_g_e___e_r_r_o_r_._a_l_m This module resides in bound_page_control in hardcore. It generates a standard audit message for the "excessive segment state changes" event. The audit message is generated internally because of the unique environmental constraints (i.e. wired) that cannot be placed on the standard auditing modules. _n_o_n_s_t_a_n_d_a_r_d _m_e_s_s_a_g_e_s There are a number of modules which generate audit message in non-standard formats. These are listed in the System Administration Procedures manual AK50. It is expected that these will be converted to use the standard modules. 4-20 Security Auditing MDD-029 SECTION 5 MEETING ORANGE BOOK REQUIREMENTS This section gives a more detailed analysis of the Orange Book requirements with respect to the Multics system architecture. _M_A_I_N_T_A_I_N_I_N_G _T_H_E _A_U_D_I_T _T_R_A_I_L "The TCB shall be able to create, maintain, and protect from modification or unauthorized access or destruction an audit trail of accesses to the objects it protects. The audit data shall be protected by the TCB so that read access to it is limited to those who are authorized for audit data." The Multics system logging mechanism (described in MDD024 "System Logging") provides the foundation for maintenance of the security audit trail. The syserr, answering service, admin, and some message coordinator logs are used to store messages which comprise the audit trail. These logs are writable only by the TCB, read access is controlled through system administrator operations. _E_V_E_N_T_S _T_O _B_E _A_U_D_I_T_E_D "The TCB shall be able to record the following types of events: ..." The following paragraphs describe the events which must be audited. _I_&_A "... use of identification and authentication mechanisms, ..." All operations of the answering service, in response to system access attempts, must be audited. Most of these entries appear 5-1 MDD-029 Security Auditing in the answering service log. The AS uses as_access_audit_ to generate most of these message (lg_ctl_ generates some directly, with a different text format, some others are completely non-standard - refer to AK50). _I_n_t_r_o_d_u_c_t_i_o_n _o_f _O_b_j_e_c_t_s _i_n_t_o _A_d_d_r_e_s_s _S_p_a_c_e "... introduction of objects into a user's address space (e.g. file open, program initiation), ..." Accesses to segments, directories, rcp objects, message segments, etc. must be audited. This includes initiation of segments, attachment of rcp objects, reading of messages, etc. Ring 0 objects are audited via access_audit_ directly, ring 1 objects are audited through the access_audit_r1_ transfer vector. _O_b_j_e_c_t _D_e_l_e_t_i_o_n "... deletion of objects, ..." Any deletion or removal of an object from the address space is to be audited. This includes segment deletion, rcp object detachment, message deletion, etc. _O_p_e_r_a_t_o_r _a_n_d _A_d_m_i_n_i_s_t_r_a_t_o_r _O_p_e_r_a_t_i_o_n_s "... and actions taken by computer operators and system administrators and/or system security officers." Operator command usage must be audited. The answering service log and the admin log together record all console input. The operator is identified by the console signon/signoff mechanism. These audit trails appear in the admin log. In addition, use of the send_admin_command is audited in the admin log (for successful usage) and the answering service log (for denied usage). Output resulting from the command line appears in the admin log. Use of the send_daemon_command is logged in the answering service log. Output resulting from the daemon's execution of the command line appears in its message coordinator log (if it is being generated). Administrator operations are audited by the TCB functions. _O_v_e_r_-_R_i_d_e _o_f _M_a_r_k_i_n_g_s "The TCB shall also be able to audit any override of human-readable output markings." 5-2 Security Auditing MDD-029 The IO daemon enters an audit message into the syserr log whenever the default output labels are overridden. It uses access_audit_gate_. _C_o_v_e_r_t _C_h_a_n_n_e_l_s "The TCB shall be able to audit the identified events that may be used in the exploitation of covert storage channels." All covert channels found in the covert channel analysis to be of a bandwidth greater than 1 bit per second are audited. _O_t_h_e_r _E_v_e_n_t_s The previous sections quote a paragraph in the Orange Book "Part I: The Criteria". However, there are additional requirements mentioned in "Part II: Rationale and Guidelines". In particular, section 5.3.2 states "... a trusted computer system must provide authorized personnel with the ability to audit any action that can potentially cause access to, generation of, or effect the release of classified or sensitive information." In section 7.4 portions of DoD Manual 5200.28-M as quoted as stating "... The log should record security related transactions, including each access to a classified file and the nature of the access ...". In Multics, the interpretation is that any action that is controlled by some security check (i.e. ACL, ring, or AIM check) is to be audited. For example, the hcs_$set_bc_seg function, since it checks for "write" effective access on the segment, should be audited. _A_U_D_I_T _T_R_A_I_L _C_O_N_T_E_N_T_S "For each recorded event, the audit record shall identify: * date and time of the event, * user, * type of event, * and success or failure of the event. For identification/authentication events the origin of request (e.g., terminal ID) shall be included in the audit record. For events that introduce an object into a user's address space and for object deletion events the audit record shall include the name of the object and the object's security level." 5-3 MDD-029 Security Auditing The text and binary of audit messages contain all this information. See AK50 and access_audit_bin_header.incl.pl1. _A_U_D_I_T _T_R_A_I_L _S_E_L_E_C_T_I_V_I_T_Y "The ADP system administrator shall be able to selectively audit the actions of any one or more users based on individual identity and/or object security level." There are two dimensions to audit trail selectivity. The first is concerned with presenting a subset of the entries in the audit trail. This is possible through use of the print_sys_log message selection control arguments. Messages can be selected by matching the user and/or object name. The second dimension is filtering at the time of the event. Certain audit messages may never be interesting to a particular administrator. There is a system performance advantage to be gained if generation of these messages is skipped. Through judicious setting of system auditing thresholds, and process auditing flags, an administrator can significantly reduce the number of audit messages generated. _G_U_I_D_E_L_I_N_E_S _F_O_R _A_U_D_I_T_I_N_G MAB068 "Multics Configuration Management: Programming Standards" contains some guidelines for when auditing should be done (in the section "Rules for Coding Trusted Software"). The applicable paragraph is repeated here: - At the time an access decision is made. An audit message is to be generated whether access is granted or denied. This includes decisions with respect to objects or facilities. - When objects are created or destroyed. Whenever a TCB supported object is created or deleted an audit message shall be generated. This includes objects such as segments, directories, message segments entries, RCP resources, processes, etc. - When security parameters are changed. The most obvious examples of this are the system-wide audit flags and thresholds, the per-process audit flags, per-process AIM privileges, reclassification of TCB supported objects, etc. 5-4 Security Auditing MDD-029 - At the time some object is made accessible for use by a process and at the time it is made inaccessible. Some examples are: Object made accessible Object made inaccessible ---------------------- ------------------------ initiate a segment terminate a segment attach a volume detach a volume (This generates audit messages which bracket the time interval within which the object was in use by a process.) What information is necessary: The TCB module must supply a number of data items to the access_audit_* routine. Thus, the TCB module must be structured in such a way that this data is available at the time access_audit_* is to be called. module name entry name of caller process validation level level at which request was made status whether the operation was granted or denied administrative operation whether the operation was administrative in nature e.g. PNT updates, PDT installs, etc. privileged operation privileged gate entry or AIM privilege invoked covert channel operation is the operation potentially useful as a covert channel? what is the bandwidth? is process a receiver or a transmitter? (see Covert Channel Analysis Report) access_operations_ entry see access_operations_.alm for entry which describes the operation (may need new one defined) name of object pathname of file system object, type and name of RCP resource, name of PNT entry, etc. access class of object AIM label of object being operated upon system status code optional value of error_table_ entry pertinent to the operation (usually upon denials) added info an ioa_ control string and optional arguments for insertion. This may be any additional information pertinent to the operation. user info 5-5 MDD-029 Security Auditing for proxy operations the user_id, authorization, min and max authorization, validation_level, process_id, and process audit flags of the requesting process must be supplied (this is all available in message segment entries typically used for daemon requests) _S_u_b_s_y_s_t_e_m _C_o_n_s_i_d_e_r_a_t_i_o_n_s _- _T_h_e _A_c_c_e_s_s _K_e_r_n_e_l Part of a B2 security evaluation is code perusal. It is here that the evaluation team tries to convince themselves that all TCB subsystems adhere to the security policy. This is very difficult if access decisions are scattered throughout the system. All access decisions should be centralized in a single module. This is referred to as the "access kernel". With this approach careful perusal of only that module is needed. Other subsystem modules are given a quick scan to determine whether they call upon the access kernel before performing any operation. Thus, it is easier to convince oneself that a subsystem adheres to the security policy. The access kernel is also responsible for security auditing. All auditing should be done at the point of the access decision. As it is determined whether access will be granted or denied, the access kernel will call access_audit_ (or one of the other modules as appropriate). It may turn out, for granted operations, that the operation does not actually complete. For instance, when creating a segment, the file system will generate a "granted" audit trail entry if the user has append permission on the target directory. Later, upon directory perusal, it may be found that an entry with the desired name already exists. The operation is, of course, aborted. However, no attempt is made to withdraw the audit message. Nor is another audit message generated to document the event (although, in some cases, an error message may appear in the syserr or answering service log). The audit trail is NOT meant to be a system journal. It is meant to record attempts to access the system or objects in the system. Whether the operation, which the system allowed the user to pursue, was completed is uninteresting from the security point of view. Some examples of access kernels in MR11 are: dc_find, rcp_access_kernel_, and mseg_check_access_. 5-6 Security Auditing MDD-029 SECTION 6 SECURITY Generation of audit trail entries is performed exclusively by the TCB. The system administrator controls access to the log segments. Only the TCB should have access to write in the system logs which hold audit messages. Only trusted users should have read access to the logs. See MDD-024 "System Logging" for more detail on setting log access. 6-1 Security Auditing MDD-029 SECTION 7 FUTURE ENHANCEMENTS This section outlines some areas for future improvement in the system security auditing trail support. _M_e_t_e_r_i_n_g Some improvements can be made to the metering of audit modules. Section 4 outlined some changes to the format of the meters in active_hardcore_data. A metering command to present these meters is also desired. _L_i_s_t_i_n_g _A_c_c_e_s_s _O_p_e_r_a_t_i_o_n_s _T_a_b_l_e The "System Administration Procedures" manual (AK50) contains a list of all the entries in access_operations_.alm. This is because there is no convenient way to display that table. A command to display it should be written. Then the list in AK50 can be removed. _S_e_c_u_r_i_t_y _T_r_a_i_l _P_e_r_u_s_a_l _T_o_o_l_s Some specialized tools to peruse audit trail entries would be helpful. Especially any that could highlight intervals of messages which might indicate attempts to subvert the system. _P_e_r_-_o_b_j_e_c_t _A_u_d_i_t _C_o_n_t_r_o_l _F_l_a_g_s Control of auditing for object classes was found to be too coarse in some instances. For example, a security administrator may desire to monitor all segment initiations. However, initiations of the segments in the system executable libraries is not interesting. Unfortunately, there is no way to distinguish between system and non-system segments. 7-1 MDD-029 Security Auditing What is needed is a pair of flags associated with an object. The first would indicate that use of the object is never to be audited. The second would indicate that use of the object is always to be audited regardless of other audit control flags and thresholds. Of course, setting of these flags would be a highly privileged operation. Additional flags may be defined to control auditing of a group of objects. For example, some flags in a directory header may be used to control auditing of all segments within that directory. The interaction of these "hierarchy" flags with the "per-object" flags discussed in the previous paragraph must be carefully considered. One major question is how these flags are to be handled by the system backup/recovery mechanisms. One certainly doesn't want to set the same flags on a segment that is cross-retrieved into a second hierarchy or onto a different system. Yet, it is desirable to restore the flags for general storage system recovery. 7-2 Security Auditing MDD-029 APPENDIX A ACCESS_AUDIT_ DOCUMENTATION This section documents the calling sequences of all the entrypoints in access_audit_ and access_audit_util_. Users outside ring 0 can call the module in the same way through the appropriate entry in access_audit_r1_ or access_audit_gate_. _A_C_C_E_S_S___A_U_D_I_T___$_C_H_E_C_K___* The access_audit_$check_* entrypoints make a determination of whether an audit message should be generated for the given operation. A single bit flag is returned to the caller. If auditing is not required, the caller may avoid expensive audit setup procedures. The general declaration and calling sequence is: dcl access_audit_$check_general entry (PARM_DCLS) returns (bit (1) aligned)); if access_audit_$check_general (PARMS) then do; /* perform audit setup */ call access_audit_$log_general (LOG_PARMS); end; There are a number of access_audit_$check_* entrypoints for ease of use by various subsystems. They allow the caller to provide the access class of an arbitrary object, a pointer to a storage system object, or a pointer to the directory entry of a storage system object. The event_flags and oper_code provide the information necessary for inspecting the process audit flags in respect to the event. The object_class provides the information necessary for inspecting the system audit thresholds. The entrypoints are provided in pairs. The first of a pair is to be called when an operation is performed within a process for the benefit of that process. The second of the pair is to be called when the operation is performed for the benefit of another A-1 MDD-029 Security Auditing process by a proxy (trusted user). This second entrypoint accepts information about the user process to determine whether auditing is required (i.e. the user's audit flags and access authorization). The following provides the required declarations for the parameters given to the various entrypoints: event_flags (bit (36) aligned) is a set of flags supplied by the caller which describes particulars of an event. It's format is given in access_audit_eventflags.incl.pl1. (The flags include special_op, grant, admin_op, priv_op, cc_1_10, cc_10_100, and receiver.) oper_code (bit (36) aligned) is the value of an entry in access_operations_. It is a coding as defined in access_operations_.alm. The caller may supply a value for the "detailed_operation" field - but must remember to define an include file describing the meaning of the different values to be included in AK50. obj_class_range ((2) bit (72) aligned) is the access class range of the object in question. This is used for objects such as RCP devices and communications channels. obj_class (bit (72) aligned) is the access class of the object in question. obj_path (char (*)) is the pathname of a segment or directory which is the object in question. obj_ptr (pointer) is a pointer to the storage-system object in question. From this, the access_audit_ module will obtain a directory entry pointer which will allow it to reference the object's access class and name. obj_entry_ptr (pointer) is a pointer to the directory entry of the storage-system object in question. The access_audit_ module will reference the object's name and access class from the entry. user_auth (bit (72) aligned) is the authorization level of the user for which the operation is being done. user_audit_flags (bit (36) aligned) is the per-process audit flag string of the user for which the operation is being done. A-2 Security Auditing MDD-029 _a_c_c_e_s_s___a_u_d_i_t___$_c_h_e_c_k___g_e_n_e_r_a_l_(___u_s_e_r_) dcl access_audit_$check_general entry (event_flags, oper_code) returns (bit (1) aligned); dcl access_audit_$check_general_user entry (event_flags, oper_code, user_auth, user_audit_flags) returns (bit (1) aligned); These two entries are used when there is no object associated with the event (e.g. setting privileges, sending a wakeup). Thus, no access class is supplied. _a_c_c_e_s_s___a_u_d_i_t___$_c_h_e_c_k___o_b_j___c_l_a_s_s___r_a_n_g_e_(___u_s_e_r_) dcl access_audit_$check_obj_class_range entry (event_flags, oper_code, obj_class_range) returns (bit (1) aligned); dcl access_audit_$check_obj_class_range_user entry (event_flags, oper_code, obj_class_range, user_auth, user_audit_flags) returns (bit (1) aligned); These two entries are used when the object involved is not a storage system entity (e.g. tape volumes) and whose access class is a range. The caller supplies the access class range of the object in question. _a_c_c_e_s_s___a_u_d_i_t___$_c_h_e_c_k___o_b_j___c_l_a_s_s_(___u_s_e_r_) dcl access_audit_$check_obj_class entry (event_flags, oper_code, obj_class) returns (bit (1) aligned); dcl access_audit_$check_obj_class_user entry (event_flags, oper_code, obj_class, user_auth, user_audit_flags) returns (bit (1) aligned); These two entries may be used for storage system objects or non storage system objects where the access class is not a range. The caller supplies the access class value of the object in question. A-3 MDD-029 Security Auditing _a_c_c_e_s_s___a_u_d_i_t___$_c_h_e_c_k___o_b_j___p_a_t_h_(___u_s_e_r_) dcl access_audit_$check_obj_path entry (event_flags, oper_code, obj_path) returns (bit (1) aligned); dcl access_audit_$check_obj_path_user entry (event_flags, oper_code, obj_path, user_auth, user_audit_flags) returns (bit (1) aligned); These two entries are used when the object involved is a storage system object. The caller supplies the pathname of the object in question. The access class is then determined internally. _a_c_c_e_s_s___a_u_d_i_t___$_c_h_e_c_k___o_b_j___p_t_r_(___u_s_e_r_) dcl access_audit_$check_obj_ptr entry (event_flags, oper_code, obj_ptr) returns (bit (1) aligned); dcl access_audit_$check_obj_ptr_user entry (event_flags, oper_code, obj_ptr, user_auth, user_audit_flags) returns (bit (1) aligned); These two entries are used when the object involved is a storage system object. The caller supplies a pointer to the object in question. The access class is then determined internally. _a_c_c_e_s_s___a_u_d_i_t___$_c_h_e_c_k___e_n_t_r_y___p_t_r_(___u_s_e_r_) dcl access_audit_$check_entry_ptr entry (event_flags, oper_code, obj_entry_ptr) returns (bit (1) aligned); dcl access_audit_$check_entry_ptr_user entry (event_flags, oper_code, obj_entry_ptr, user_auth, user_audit_flags) returns (bit (1) aligned); These two entries are also used when the object involved is a storage system object. In this case the caller supplies a pointer to the directory entry of the object in question. The access class is extracted from the entry. These entries cannot be called outside of ring 0. A-4 Security Auditing MDD-029 _A_C_C_E_S_S___A_U_D_I_T___$_L_O_G___* The access_audit_$log_* entries form the actual audit message for logging. There are a number of entrypoints for ease of use by various TCB subsystems. In general, each entrypoint is supplied with the name of the caller, a set of event specific flags, the access operation code, a related error code, a structure of binary data, and a textual message. As with the access_audit_$check_* entries, separate logging entries are provided which require the access class of an arbitrary object, a pointer to a storage system object, or a pointer to the directory entry of a storage system object. Also, pairs of entries are provided for proxy and non-proxy type operations. These entries check whether auditing is required regardless of whether the calling subsystem has already called an access_audit_$check_* entrypoint in respect to the same operation. The following paragraphs define the parameters used in the access_audit_$log_* entrypoints. caller (char (*)) is the name of the caller. This will be added to the text portion of the log entry. caller_level (fixed bin) is the validation level of the caller. This is especially important when an operation involves multiple rings. For instance, the validation level of someone creating a mailbox from the normal user ring should be "4", not "1" as hardcore would perceive. event_flags (bit (36) aligned) (Same as for access_audit_$check_*.) oper_code (bit (36) aligned) (Same as for access_audit_$check_*). obj_class_range ((2) bit (72) aligned) (Same as for access_audit_$check_*). obj_class (bit (72) aligned) (Same as for access_audit_$check_*). obj_path (char (*)) (Same as for access_audit_$check_*). obj_ptr (pointer) (Same as for access_audit_$check_*). obj_entry_ptr (pointer) (Same as for access_audit_$check_*). A-5 MDD-029 Security Auditing obj_name (char (*)) is the textual name of the object associated with the event to be audited. This argument is required only for those logging entries which may deal with non-storage-system objects. It is used only for insertion in the default audit message text. error_code (fixed bin (35)) is a standard system error code or 0. This is a code associated with the event being audited. info_ptr (pointer) is a pointer to binary information to be included in the logged audit message. The first 9 bits must specify the type of binary structure which describes the data (see access_audit_binary_def.incl.pl1). This will be used to form the name of a routine that can be called to format the binary information for display ("format_XXXXXXXX_audit_info_"). A null value indicates there is no binary info. If null, and the object is a storage system entity, binary info compatible to format_ssobj_audit_info_ will be generated (see access_audit_ssobj_info.incl.pl1). The binary information is inserted into the data portion of the system log message preceded by the audit_record_header. info_size (fixed bin (21)) is the size (in words) if the binary information. It should be 0 if no information is provided. user_info_ptr (pointer) is a pointer to a structure of user data. Included is the user's user_id, validation level, authorization, max authorization, audit flags, and process_id. The structure is included in access_audit_user_info.incl.pl1. msg_str (char (*)) is a control string (acceptable to formline_) which contains any added textual information and the control characters needed to format any supplied optional arguments. The formatted string is placed into the text portion of the standard system audit message. optional args (any type acceptable to formline_) are those arguments to be formatted by the control characters in msg_str. _a_c_c_e_s_s___a_u_d_i_t___$_l_o_g___g_e_n_e_r_a_l_(___u_s_e_r_) dcl access_audit_$log_general entry (caller, caller_level, event_flags, oper_code, A-6 Security Auditing MDD-029 obj_name, error_code, info_ptr, info_size {, msg_str, optional args}); dcl access_audit_$log_general_user entry (caller, caller_level, event_flags, oper_code, obj_name, error_code, info_ptr, info_size, user_info_ptr {, msg_str, optional args}); These two entries enter an audit log message for events not related to storage-system objects (e.g. privilege setting, sending wakeup). Example: oper_code = access_operations_$set_priv_rcp; unspec (auto_event_flags) = ""b; auto_event_flags.special_op = "1"b; auto_event_flags.grant = "1"b; auto_event_flags.priv_op = "1"b; call access_audit_$log_general ("set_priv", level$get, unspec (auto_event_flags), oper_code, "", 0, null, 0, "Set RCP privilege."); _a_c_c_e_s_s___a_u_d_i_t___$_l_o_g___o_b_j___c_l_a_s_s___r_a_n_g_e_(___u_s_e_r_) dcl access_audit_$log_obj_class_range entry (caller, caller_level, event_flags, oper_code, obj_class_range, obj_name, error_code, info_ptr, info_size {, msg_str, optional args}); dcl access_audit_$log_obj_class_range_user entry (caller, caller_level, event_flags, oper_code, obj_class_range, obj_name, error_code, info_ptr, info_size, user_info_ptr {, msg_str, optional args}); These two entries are used when the involved object is not a storage-system entity. The caller must supply the access class range of the object in question. Example: oper_code = access_operations_$rcp_tape_read; addr (oper_code) -> encoded_access_op.detail_operation = unspec (rcp_codes); unspec (auto_event_flags) = ""b; auto_event_flags.priv_op = "1"b; call access_audit_$log_obj_class_range ("rcp_mount_", level$get, unspec (auto_event_flags), oper_code rcpr_entry.access_class, rcpr_entry.volume_name, error_table_$ai_restricted, null(), 0); A-7 MDD-029 Security Auditing _a_c_c_e_s_s___a_u_d_i_t___$_l_o_g___o_b_j___c_l_a_s_s_(___u_s_e_r_) dcl access_audit_$log_obj_class entry (caller, caller_level, event_flags, oper_code, obj_class, obj_name, error_code, info_ptr, info_size {, msg_str, optional args}); dcl access_audit_$log_obj_class_user entry (caller, caller_level, event_flags, oper_code, obj_class, obj_name, error_code, info_ptr, info_size, user_info_ptr {, msg_str, optional args}); These two entries are used when the involved object is not a storage-system entity. The caller must supply the access class of the object in question. Example: oper_code = access_operations_$mseg_del_msg; unspec (auto_event_flags) = ""b; auto_event_flags.admin_op = "1"b; call access_audit_$log_obj_class ("mseg_", level$get, unspec (auto_event_flags), msg.class, recipient, error_table_$ai_restricted, addr (msg), size (msg)); _a_c_c_e_s_s___a_u_d_i_t___$_l_o_g___o_b_j___p_a_t_h_(___u_s_e_r_) dcl access_audit_$log_obj_path entry (caller, caller_level, event_flags, oper_code, obj_path, error_code, info_ptr, info_size {, msg_str, optional args}); dcl access_audit_$log_obj_path_user entry (caller, caller_level, event_flags, oper_code, obj_path, error_code, info_ptr, info_size, user_info_ptr {, msg_str, optional args}); These two entries are used when the object involved is a storage system entity. The caller supplies the pathname of the actual object. Example: oper_code = access_operations_$seg_read; unspec (auto_event_flags) = ""b; auto_event_flags.grant = "1"b; call access_audit_$log_obj_ptr_user ("imft_get_", level$get, unspec (auto_event_flags), oper_code, seg_path, 0, addr(seg_info_struct), size(seg_info_struct), addr(user_audit_info), "Copying to IMFT host ^a.", imft_request.dest); A-8 Security Auditing MDD-029 _a_c_c_e_s_s___a_u_d_i_t___$_l_o_g___o_b_j___p_t_r_(___u_s_e_r_) dcl access_audit_$log_obj_ptr entry (caller, caller_level, event_flags, oper_code, obj_ptr, error_code, info_ptr, info_size {, msg_str, optional args}); dcl access_audit_$log_obj_ptr_user entry (caller, caller_level, event_flags, oper_code, obj_ptr, error_code, info_ptr, info_size, user_info_ptr {, msg_str, optional args}); These two entries are used when the object involved is a storage system entity. The caller supplies a pointer to the actual object. Example: oper_code = access_operations_$seg_read; unspec (auto_event_flags) = ""b; auto_event_flags.grant = "1"b; call access_audit_$log_obj_ptr_user ("imft_get_", level$get, unspec (auto_event_flags), oper_code, seg_ptr, 0, addr(seg_info_struct), size(seg_info_struct), addr(user_audit_info), "Copying to IMFT host ^a.", imft_request.dest); _a_c_c_e_s_s___a_u_d_i_t___$_l_o_g___e_n_t_r_y___p_t_r_(___u_s_e_r_) dcl access_audit_$log_entry_ptr entry (caller, caller_level, event_flags, oper_code, obj_entry_ptr, error_code, info_ptr, info_size {, msg_str, optional args}); dcl access_audit_$log_entry_ptr_user entry (caller, caller_level, event_flags, oper_code, obj_entry_ptr, error_code, info_ptr, info_size, user_info_ptr {, msg_str, optional args}); These two entries also are used when the object involved is a storage-system entity. The caller supplies a pointer to the directory entry of the object in question. This entry is not available outside of ring 0. Example: oper_code = access_operations_$dir_status; unspec (auto_event_flags) = ""b; call access_audit_$log_entry_ptr ("status_", level$get, unspec (auto_event_flags), oper_code, addr(entry), error_table_$no_s_permission, addr(entry), size(entry), "Unable to list contents."); A-9 MDD-029 Security Auditing _a_c_c_e_s_s___a_u_d_i_t___$_l_o_g___n_o___p_r_o_c_e_s_s dcl access_audit_$log_no_process entry (caller, caller_level, event_flags, oper_code, obj_name, error_code, info_ptr, info_size, user_group_id {, msg_str, optional args}); This is a special entry used by the answering service for logging events associated with no process (e.g. user in connect loop). "user_group_id" is a string of the form "Person_ID.Project_ID.Tag" referring to the user on whose behalf the operation is performed. _A_C_C_E_S_S___A_U_D_I_T___U_T_I_L___$_* This section describes some miscellaneous entries in the access_audit_util_ module. _a_c_c_e_s_s___a_u_d_i_t___u_t_i_l___$_g_e_t___m_e_t_e_r_s dcl access_audit_$get_audit_meters entry (area_ptr, n_buckets, meter_info_ptr, err_code); This entry returns the value of the metering data stored in active_hardcore_data. "area_ptr" is a pointer to user's area (input). "n_buckets" is a fixed binary number representing the number of metering data "buckets" returned (output). "meter_info_ptr" is a pointer set to the structure allocated in the supplied area (see access_audit_meter_info.incl.pl1). "err_code" is a standard system status code. _a_c_c_e_s_s___a_u_d_i_t___u_t_i_l___$_g_e_t___a_u_d_i_t___f_l_a_g_s dcl access_audit_$get_audit_flags entry (flags); This entry returns the value of the audit flags for the current user. "flags" is a bit (36) aligned value returned to the caller. Its format is defined in access_audit_flags.incl.pl1. _a_c_c_e_s_s___a_u_d_i_t___u_t_i_l___$_s_e_t___a_u_d_i_t___f_l_a_g_s dcl access_audit_$set_audit_flags entry (flags); This entry sets the value of the audit flags for the current user. "flags" is a bit (36) aligned value supplied by the A-10 Security Auditing MDD-029 caller. Its format is defined in access_audit_flags.incl.pl1. Changing of a process' audit flags is suggested only for experimental or debugging purposes. This entrypoint is available only through hphcs_ and admin_gate_. ----------------------------------------------------------- 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