Solaris Auditing

Solaris auditing helps to detect potential security breaches by revealing suspicious or abnormal patterns of system usage. Solaris auditing also provides a means to trace suspect actions back to a particular user, thus serving as a deterrent. Users who know that their activities are being audited are less likely to attempt malicious activities. The CIS Solaris 10 Security Benchmark enabled and configured Solaris Auditing in a section titled “Enable Kernel Level Auditing”.

Audit Policy Configuration

In addition to selecting which events to audit, globally or for specific users, Solaris Auditing also supports a number of other configuration options. These configuration options are specified using the auditconfig program and stored in the /etc/security/audit_startup file. A few of the most often used policy settings are listed in the following table. For more information on each of these options as well as how they can be set, see auditconfig(1M):

Audit Policy VariableDescription
ahlt Halt the machine if an asynchronous audit event occurs that cannot be delivered because the audit queue has reached the high-water mark or because there are insufficient resources to construct an audit record. By default, this option is not set and audit records are dropped (when either of these conditions occurs) and a count is kept of the number of dropped records. This count can be queried using the auditstat(1M) command.
arge Include the execv(2) system call environment arguments to the audit record. This information is not included by default in Solaris, but it is enabled by the CIS item titled “Enable Kernel Level Auditing”.
argv Include the execv(2) system call parameter arguments to the audit record. This information is not included by default in Solaris, but it is enabled by the CIS item titled “Enable Kernel Level Auditing”.
public Audit public files. By default, read- type operations are not audited for certain files which meet public characteristics: owned by root, readable by all, and not writable by all. This option, when enabled, helps to reduce some of the non-security relevant events or “noise” commonly found in audit trails.
seq Include the sequence token as part of every audit record. By default, the sequence token is not included. The sequence token attaches a sequence number to every audit record.
zonename Include the zonename token as part of every audit record. By default, the zonename token is not included. The zonename token gives the name of the zone from which the audit record was generated.

Audit Record Selection and Display

Once Solaris Auditing has been enabled, organizations can use the audit trails to better understand what actions are being taken on their systems. In particular, the commands auditreduce(1M) and praudit(1M) can be used to select and display events respectively.

For example, the following audit record shows that the user mchurchi successfully used the su command to access a root shell in the global zone on egmp02-01:

# auditreduce -u mchurchi -m AUE_su | praudit -s
header,104,2,AUE_su,,egmp02-1,2007-09-23 15:29:00.248 -04:00
subject,mchurchi,root,mchurchi,mchurchi,mchrchui,692,2868335681,0 0
text,success for user root

This same information can also be represented in XML in the Solaris 10 OS:

# auditreduce -u gbrunett -m AUE_su | praudit -x
<?xml version='1.0' encoding='UTF-8' ?>
<?xml-stylesheet type='text/xsl'
href='file:///usr/share/lib/xml/style/adt_record.xsl.1' ?>
<!DOCTYPE audit PUBLIC '-//Sun Microsystems, Inc.//DTD Audit V1//EN'
<file iso8601="2007-09-23 15:29:00.000 -04:00"></file>
<record version="2" event="su" host="egmp02-01" iso8601="2007-09-23
15:29:00.248 -04:00">
<subject audit-uid="mchurchi" uid="root" gid="mchurchi" ruid="mchurchi"
rgid="mchurchi" pid="692" sid="2868335681" tid="0 0 egmp02-01"/>
<text>success for user root</text>
<return errval="success" retval="0"/>
<zone name="global"/>
<file iso8601="2007-09-23 15:29:00.000 -04:00"></file>

Similarly, in the Solaris 10 OS, Solaris Auditing can be configured to forward audit events to syslog. Regardless of whether the use of syslog has been configured, audit events are always also recorded on the local system. When using the syslog plugin, the above audit event would be recorded as:

Sep 23 15:29:00 egmp02-01 audit: [ID 702911 audit.notice] su ok session
2868335681 by mchurchi as root:mchurchi in global from egmp02-01 text
success for user root


For more information on Solaris Auditing, see: