Audit methodology

This section explains how the audit subsystem functions, what criteria are used to collect data, and how audit requirements affect system performance.

Audit privileges

There are four privileges associated with the audit subsystem:

• The configaudit kernel authorization allows the audit parameters for all users of the system to be set.

• The writeaudit kernel authorization allows specific information to be recorded in the audit trail.

• The suspendaudit kernel authorization prevents any auditing.

• The audittrail secondary subsystem authorization allows users to generate audit reports on their own activities. When a user is assigned this authorization, they can access the Report selections of the Audit Manager.

Audit record sources

The audit trail contains the security-related events for the system. Effective auditing tracks not only system call requests from user processes but also certain events such as login, logoff, and login failure attempts. These events are critical to determining who has accessed the system, when, where (from what terminal), and what was done. Login failures are impossible to audit at the kernel level because the kernel has no knowledge of what an application is specifically doing. Thus, certain security-critical utilities such as login must be allowed to generate audit records.

Kernel audit mechanism

A large percentage of the audit records stored in the audit trail are generated by the kernel audit mechanism. This portion of the audit subsystem generates records in response to user process system calls that map to security-related events. Some system calls, open(S) for example, map to multiple security events depending upon user arguments and the state of the file being opened. If open(S) is called with the O_CREAT flag, the file is created if it does not exist. If the O_TRUNC flag is specified, the file is truncated to zero length if it exists. This illustrates how the open(S) call could map to one of three distinct events: Make Object Available, Object Creation, or Object Modification.

Error codes also play an important role in determining the event. Errors on system calls that indicate access or permission denials as well as resource consumption problems are mapped to specific event types. The kernel audit mechanism determines at the end of the system call what event class the call belongs to, and whether that event is to be audited. In addition, the mechanism may apply additional selection criteria such as user ID or group ID. In this manner, the generation of audit records can be limited to a select group of users.

Trusted applications

The Trusted Computing Base (TCB) contains a number of trusted applications essential to providing a trusted environment. Among these are login, su, and various audit subsystem commands. To reduce the amount of audit data written to the audit trail, and to make the trail more meaningful, these trusted applications are permitted to write directly to the audit device. This enables login, for example, to write a login audit record to the audit trail rather than letting a login on the system be represented as a collection of system calls required to complete the login procedure.

It is not sufficient to just let the trusted applications write to the audit device. There must also be a way to suppress the generation of system call audit records by the kernel audit mechanism to avoid the problem of a cluttered audit trail. Thus, trusted applications run with the suspendaudit privilege, suspending kernel system call auditing for that process and allowing them to open and write the audit device. Only a few trusted applications are permitted to do this. A user process should not run with suspendaudit privilege. The privilege mechanism is managed by login, using restricted system calls, and is based on Protected Password database entries.

Authorized subsystems

A third method in which audit records are generated is through authorized subsystems such as the lp, cron, terminal, and mem subsystems. Sometimes, a subsystem encounters inconsistencies or problems that make the writing of an informative audit record desirable. However, subsystems do not possess the writeaudit privilege and cannot directly write audit records to the subsystem.

Instead, the subsystems format the records just as a trusted application would, and present the records to the audit daemon process through a trusted interface. The audit daemon, which is a trusted application, performs the task of writing the audit record to the audit device. This allows concise and informative audit records to be generated by protected subsystem processes without having to distribute the writeaudit privilege to these systems.

Accountability for audit

The audit subsystem audits security-related system events and associates the events with a specific user. Users log into the system through the login program. This program performs authentication on the user to determine whether access is permitted. The login procedure provides audit support for both successful and unsuccessful login attempts. When a user is successfully logged in, login stamps the user process with the login user ID (LUID). Regardless of the number of setuid(S) and setgid(S) system calls made by that process, the LUID does not change. Strict accountability is maintained for the process and the user. A user process may still perform setuid and setgid system calls, which are also audited. The audit records indicate the LUID of the process together with the effective and real user and group IDs of the process.

Audit event types

Every audit record, regardless of the originator, is stamped with an event type. For user process system calls, the event type is determined by the kernel audit mechanism, based on the system call and its outcome. For application or subsystem auditing, the process writing the audit record sets the event type. This event type is not changed by the audit device or by the audit daemon.

Event types are important because they classify the security event on the system. Both audit-record generation and reduction can be controlled based on event types. For example, if you are only concerned with users logging onto and off the system, you can specify that event type for collection or reduction.

The audit subsystem provides a wide range of event types that strike a balance between granularity and relevant security classes. These events are summarized in ``Audit events''; the letters are simple identifiers used to refer to the event by the audit subsystem (see ``Audit event descriptions'' for a more detailed list).

Audit events

A.	Startup/Shutdown	B.	Login/Logoff
C.	Process Create/Delete	D.	Make Object Available
E.	Map Object to Subject	F.	Object Modification
G.	Make Object Unavailable	H.	Object Creation
I.	Object Deletion	J.	DAC Changes
K.	DAC Denials	L.	Admin/Operator Actions
M.	Insufficient Authorization	N.	Resource Denials
O.	IPC Functions	P.	Process Modifications
Q.	Audit Subsystem Events	R.	Database Events
S.	Subsystem Events	T.	Use of Authorization

You can selectively collect and reduce audit data based on these event types. The audit subsystem interface lets you build a list of event types for either the audit subsystem or the data-reduction program.

The subsystem uses event types to determine whether an audit record should be written to the audit trail. As the audit administrator, you have full control over what events get audited.

To control event type auditing, the subsystem contains a global system audit event mask. The audit subsystem also maintains a mask of event types for each process on the system.

System audit event mask

The system event mask is global to the audit subsystem. You can change it during auditing if you want to select a different set of events. The system event mask contains one bit for each event type; the bit is set to one when auditing is desired. This provides a fast test to determine if a newly created record is enabled for auditing. The audit subsystem uses the system event mask to compute user masks when a new process is created through a login.

User-specific and process event masks

You can override the system-wide event mask for any user by setting up a ``user-specific event mask''. Each process on the system has a ``process event mask'' that tells the system what to audit for that process. When a user logs in, the login program looks up the user-specific event mask and sets the process event mask for the login shell.

For each audit event type, the user-specific event mask has one of three values:

• always audit this event

• never audit this event

• use the system audit event mask