Using the Audit Manager

Audit subsystem components

The audit subsystem consists of five major components:

Although not actually part of the audit subsystem proper, there are also a number of trusted system utilities responsible for writing audit records to the audit trail, such as login(M).

Kernel audit mechanism

The kernel audit mechanism is central to the audit subsystem. This mechanism generates audit records based on user process activity through kernel system calls. Each kernel system call has a corresponding entry in a subsystem table that indicates whether the call is security-relevant and, if so, to what event type the system call corresponds. Additionally, a table of error codes further classifies the system calls into specific security events. The kernel audit mechanism makes an internal call to the audit device driver to write a record to the audit trail.

For example, the open(S) system call is classified as a Make object available event. If user blf performs an open(S) on /unix and it succeeds, an audit record is generated indicating that event. However, if the system call fails because blf requested write access on the open(S) but does not have write permission on the file, the action is classified as a DAC Denial event for blf with object /unix. Consequently, a system call can map to a number of event types, depending on the object accessed and/or the result of the call. It is possible that a system call might be audited selectively, depending on the event types that you enable.

Some system calls are not considered relevant to security. For example, getpid(S) retrieves the process ID of a process and does not constitute an event of security relevance. Thus, that system call is never audited.

Audit device driver

The audit device driver is responsible for:

accepting audit records from the kernel audit mechanism and from trusted utilities.
creating and writing the intermediate audit trail files.
providing audit trail data to the audit daemon for compaction.
providing for selective audit record generation based on event types, user IDs, and group IDs.

The device driver provides open(S), close(S), read(S), write(S), and ioctl(S) interfaces like many other character devices. (The audit device is described on the audit(HW) manual page.) However, the audit device can only be opened by processes having configaudit or writeaudit privileges. This limits access to the audit device only to trusted utilities such as the audit daemon and the audit administrator interfaces. The audit device can be written to by many processes at the same time. The device handles the merging of the records into the audit trail. The device can only be read by a single process, the audit daemon.

The audit device driver maintains the audit trail as a set of ``audit collection files''. Each time you enable auditing, a new audit session is begun. As the session starts, the subsystem creates a collection file into which audit records are written. When the collection file reaches a certain size, the subsystem creates a new collection file and begins writing to it this is configurable -- see ``Adjusting audit performance parameters''. The audit trail could, therefore, be viewed as a continuously growing sequential file even though many collection files are used.

Audit compaction daemon

The audit daemon auditd(ADM) is a trusted utility that runs as a background daemon process whenever you enable auditing. The daemon is the sole reader of the audit device which, in turn, provides the daemon with blocks of records from the audit collection files. The daemon is not concerned that the audit trail is spread over numerous collection files. The audit device driver satisfies the read requests from the daemon and handles the switching and deletion of collection files as needed.

The main purpose of the daemon is to provide a compaction and logging mechanism for the audit session. Depending on the audit record generation criteria you select, a large amount of audit data can be generated on the system. For a typical single-user system, it would not be uncommon to generate 200KB of audit data in an hour. The daemon provides a compaction mechanism, compressing the audit data into a packed record format that is stored in an ``audit compaction file''. The compaction algorithm provides for an average 60% reduction in file space, which greatly reduces disk space used to store audit records.

A second function of the daemon is to provide a log file describing the current audit session. The log file contains information about the number of audit records available in the compacted file's output for the session, the start and stop times of the session, and other indicators pertaining to the audit session's state. Just as the audit device driver opens a new collection file when the current one reaches a specified size, the daemon can create multiple compaction files to avoid growing a single file too large to be manageable -- this is also configurable; see ``Adjusting audit performance parameters''. Compaction files written by the daemon may also be located in a variety of administrator-specified directories. For these reasons, the log file is maintained to provide a trail of compaction files that can be used for subsequent data reduction.

A third function of the audit daemon is to serve as an interface program to the audit device driver for the writing of audit records from protected subsystems that do not have the writeaudit privilege. Because these subsystems cannot access the audit device driver directly but can interface to the daemon in a trusted manner, the daemon handles the writing of the application audit record to the subsystem.

Audit Manager interface

The Audit Manager allows the administrator to handle setup and initialization, modify subsystem parameters, maintain the subsystem (backup, restore, and so on), and reduce both general and selective audit data. You can start the Audit Manager in any of these ways:

Double-click on the Audit Manager icon in the the System/Security directory of System Administration toolshed on the Desktop.
Start the SCOadmin launcher by entering scoadmin on the command line, then selecting System Security Audit Manager.
Enter scoadmin audit manager on the command line (or abbreviate to scoadmin au).

For more information on using SCOadmin managers, see ``Administering your system with SCOadmin''.

Data reduction and analysis facility

The audit subsystem also includes a data reduction and analysis facility to examine audit trails from previous audit sessions or from the current audit session. By using the log file produced by the audit daemon, the reduction utility can identify all of the compaction files needed to reduce an audit session. Because the compaction files are in a compressed format, the reduction program contains the necessary routines to uncompress the data.

To provide effective analysis of audit data, the reduction utility lets you specify certain event types, user IDs, group IDs, and object names to reduce the data selectively. In addition, you can specify a time interval to be applied while searching for records to match the specified criteria. If a record is not within the specified time interval, it is ignored for the purpose of that reduction.

As an example, you may reduce the data selecting the DAC Denial event with user ID blf looking for the object /unix. Only records that reflect an access attempt to /unix by blf that was denied because of lack of permission are printed. This provides a powerful mechanism for identifying security events of immediate interest without having to analyze the entire audit trail.