Trusted Solaris Administration Overview

Chapter 4 Administering Auditing

This chapter introduces you to auditing in the Trusted Solaris environment. Auditing is the process of capturing user activity and other events on the system, storing this information in a set of files called an audit trail, and producing system activity reports to fulfill site security policy. Should a breach of security occur, the audit records may enable you to determine how the breach occurred and which user or users were involved. For a more complete description of the auditing process, refer to the Trusted Solaris Audit Administration guide.

Planning and Setting Up Auditing

Before you set up auditing for your site, you need to:

Decide which classes of events to audit, including any new classes or events you wish to add to your site.
Plan where to store the auditing information.
Define the audit configuration files.

Audit Classes

You need to decide which events you want to audit. You can capture user actions or non-attributable events (that is, events such as interrupts which cannot be attributed to specific users). For the user actions, you can separate successful and failed transactions. Auditing events are organized into classes in Trusted Solaris. The auditing classes for files fall into these general areas:

Open for reading
Open for writing
Attribute changes
Creations
Deletions

You can also create your own classes and events as needed and can rearrange the mapping of classes to events. Other classes keep track of such items as process operations, network events, window operations, IPC operations, administrative actions, logins, logouts, application-defined events, ioctl system calls, program executions, Xserver operations, and miscellaneous events. Because auditing information can take up a lot of disk space, you need to decide carefully which events to auditand select only the classes that contain events necessary for your site's security policy.

Public Objects

One way to reduce the amount of auditing information collected is to specify certain files and directories to be public objects. A public object typically contains read-only information, is not modifiable by normal users, and has no implications on security, eliminating the need to track who accesses the object. The system clock is a good example of a public object. When you set the public object flag, any other auditing flags specifying the object are ignored.

Audit Information Storage

The large amount of disk space needed for auditing requires that you plan carefully where the information is going will be collected.

If your site uses individual non-networked workstations, it is recommended that each workstation have a dedicated disk for audit records. The dedicated disk should have at least two partitions:

a primary storage area
a partition for holding overflow records

For a network of workstations, you should dedicate at least one separate server for collecting audit information and a second server for administering and analyzing the audit data.

In any case, you should set MAC and DAC protections on the audit files and directories to preserve their integrity and prevent snooping.

Audit Configuration Files

The specifications for auditing at a site are stored in these configuration files, which reside in the /etc/security subdirectory:

audit_control(4)--stores audit control information used by the audit daemon, including the preferred order of directories where audit information is stored (the audit daemon uses a directory until the minimum free space warning limit is reached, at which point it stores audit records in the next directory in the list), minimum free space warning limit, system-wide audit flags indicating classes to be audited, and special audit flags for events that cannot be attributed to specific users. The audit flags set in this file are applied to all users. Any exceptions to these flags are set on a per-user basis and specified in the audit_user file, which is modified using the User Accounts tool in SMC.
audit_user(4)--stores auditing criteria for users who are exceptions to the auditing specifications in audit_control. This information includes user name, events that are always to be audited, and events that are never to be audited.
audit_class(4)--stores audit class definitions, including the class mask (that is, the filter that determines which classes are to be tracked), class name, and description.
audit_event(4)--stores audit event information, including event number, event name, description, and audit flags identifying the audit class.

If you are setting up auditing for a network, there must be identical versions of the audit_class, and audit_event files on each workstation. Use the SMC to update the audit_user site-wide NIS maps and NIS+ tables..

Auditing Tools

This section describes the main utility programs and scripts for administering auditing. Auditing is enabled during system installation. You can enable or disable auditing by editing the /etc/init.d/audit script and the /etc/system file.

audit and auditd

The audit(1M) command is an interface to control the current audit daemon. The audit daemon.auditd(1M), controls the generation and location of audit trail files, using information from the audit_control file. The auditd command starts the audit daemon (if auditing has been enabled). The audit command can halt the daemon, which stops the recording but not the collection of audit records; the audit command provides other options as well for controlling the daemon.

The audit command lets you

Reset the first directory in the list of audit storage directories in the audit_control file.
Open a new audit file in the audit directory specified in the audit_control file, as last read by the audit daemon.
Signal the audit daemon to close the audit trail and halt the recording but not the collection of audit records.

auditconfig

The auditconfig(1M) command provides a command line interface to get and set kernel audit parameters, including setting various aspects of auditing policy.

audit_startup

The audit_startup(1M) script lets you configure auditing parameters during system startup. The script initializes the audit subsystem before the audit daemon is started. This script currently consists of a series of auditconfig commands to set the system default policy and download the initial event-to-class mapping. The security administrator can access audit_startup by opening the system_admin folder in the Application Manager. You can configure it as necessary for your site.

audit_warn

The audit_warn(1M) script lets you specify warnings to send out and other actions to take when the audit daemon detects problems. When a problem is encountered, the audit daemon calls audit_warn with the appropriate arguments. The option argument specifies the error type. You can specify a list of mail recipients to be notified when an audit_warn situation arises by defining a mail alias called audit_warn in aliases(4).

praudit

The praudit(1M) command prints the contents of an audit trail file in readable form.

auditreduce

The auditreduce(1M) command lets you select or merge records from audit trail files from one or more machines. The merge function merges audit records from one or more input audit trail files into a single output file. The select function lets you select audit records on the basis of criteria relating to the record's content. The merge and select functions can be combined in a script with the praudit command to produce customized reports for your site.

auditstat

The auditstat(1M) command displays kernel audit statistics, such as the number of audit records processed and how much memory is being used by the kernel audit module.