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.
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
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 the Trusted Solaris environment. 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 audit and select only the classes that contain events necessary for your site's security policy.
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.
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 systems, each system should 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 computers, 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.
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, 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 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. 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 computer. Use the SMC to update the audit_user site-wide NIS maps and NIS+ tables.
By default, auditing is enabled in the Trusted Solaris environment This section describes the main utility programs and scripts for administering auditing. See the Trusted Solaris Audit Administration guide for how to disable or re-enable auditing.
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 is 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 enables you to:
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.
The auditconfig(1M) command provides a command line interface to get and set kernel audit parameters, including setting various aspects of auditing policy.
The audit_startup(1M) script enables you to 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 the audit_startup script from the System_Admin folder in the Application Manager.
The audit_warn(1M) script enables you to 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 using the Mail Lists tool in the Users tool set in the SMC.
The praudit(1M) command prints the contents of an audit trail file in readable form.
The auditreduce(1M) command enables you to select or merge records from audit trail files from one or more hosts. The merge function merges audit records from one or more input audit trail files into a single output file. The select function enables you to 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.
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.