Using the Audit Manager

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:

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:

For each audit event type, the process audit mask is set from the user-specific mask if it indicates that the event is always or never audited. Otherwise, the process audit mask is set from the system audit event mask. In most cases, the user-specific event mask is set to the third value for all audit events, which causes the system default to apply to that user. You can use the user-specific mask to audit either more or less information about users that you trust either more or less than the rest of the user population.
Next topic: Guidelines for effective system auditing
Previous topic: Data reduction and analysis facility

© 2003 Caldera International, Inc. All rights reserved.
SCO OpenServer Release 5.0.7 -- 11 February 2003