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 <channel>
<dialid> <groupid>") 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