Configuring Audit Files (Tasks)

Before you enable auditing on your network, you can customize the audit configuration files for your site auditing requirements. You can also restart the auditing service or reboot the local system to read changed configuration files after the auditing service has been enabled. However, the recommended practice is to customize your audit configuration as much as possible before you start the auditing service.

If you have implemented zones, you can choose to audit all zones from the global zone. To differentiate between zones in the audit output, you can set the zonename policy option. Alternatively, to audit non-global zones individually, you can set the perzone policy in the global zone and customize the audit configuration files in the non-global zones. For an overview, see Auditing and Solaris Zones. For planning, see How to Plan Auditing in Zones.

How to Modify the audit_control File

The /etc/security/audit_control file configures system-wide auditing. The file determines which events are audited, when audit warnings are issued, and the location of the audit files.

1. Assume the Primary Administrator role, or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. (Optional) Save a backup copy of the audit_control file.

   # cp /etc/security/audit_control /etc/security/audit_control.orig

3. Modify the audit_control file for your site.

   Each entry has the following format:

   keyword:value

   keyword

   Defines the type of line. The types are dir, flags, minfree, naflags, and plugin. The dir line can be repeated.

   For explanations of the keywords, see the following examples. For an example of a plugin entry, see How to Configure syslog Audit Logs

   value

   Specifies data that is associated with the line type.

Example 30-1 Preselecting Audit Classes for All Users

The flags line in the audit_control file defines which classes of attributable events are audited for all users on the system. The classes are separated by commas. White space is allowed. In this example, the events in the lo class are audited for all users.

# audit_control file
dir:/var/audit
flags:lo
minfree:20
naflags:lo

To see which events are in the lo class, read the audit_event file. You can also use the bsmrecord command, as shown in Example 30-25.

Example 30-2 Preselecting Nonattributable Events

In this example, all events in the na class, and all login events that are not attributable, are audited.

# audit_control file
dir:/var/audit
flags:lo
minfree:20
naflags:lo,na

Example 30-3 Specifying the Location of Binary Audit Data

The dir lines in the audit_control file list which audit file systems to use for binary audit data. In this example, three locations for binary audit data are defined.

# audit_control file
#
# Primary audit directory - NFS-mounted from audit server
dir:/var/audit/egret.1/files
#
# Secondary audit directory - NFS-mounted from audit server
dir:/var/audit/egret.2/files
#
# Directory of last resort local directory
dir:/var/audit
flags:lo
minfree:20
naflags:lo,na
plugin:

To set up file systems to hold audit binary audit data, see How to Create Partitions for Audit Files.

Example 30-4 Changing the Soft Limit for Warnings

In this example, the minimum free-space level for all audit file systems is set so that a warning is issued when only 10 percent of the file system is available.

# audit_control file
#
dir:/var/audit/examplehost.1/files
dir:/var/audit/examplehost.2/files
dir:/var/audit/localhost/files
flags:lo
minfree:10
naflags:lo,na

The audit_warn alias receives the warning. To set up the alias, see How to Configure the audit_warn Email Alias.

How to Configure syslog Audit Logs

You can instruct the auditing service to collect only binary audit data, or you can instruct the auditing service to collect binary data and text data. In the following procedure, you collect binary audit data and text audit data. The collected text audit data is a subset of the binary data.

Before You Begin

Preselected audit classes must be specified on the flags line or the naflags line of the audit_control file. The text data is a subset of the preselected binary data.

1. Assume the Primary Administrator role, or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. (Optional) Save a backup copy of the audit_control file.

   # cp /etc/security/audit_control /etc/security/audit_control.save

3. Add a plugin entry.

   Plugins in the auditing service implement binary output and syslog output of audit data. The binary plugin is not specified. The syslog plugin must be specified. For more information, see auditd Daemon.

   A plugin entry has the following format:

   plugin:name=value; p_flags=classes

   value

   Lists the name of the plugin to use. Currently, the only valid value is the audit_syslog.so.1 plugin.

   classes

   Lists a subset of the audit classes that are specified in the flags line and the naflags line.

   For more information about the plugin value, see the audit_syslog(5) man page.

4. Add an audit.notice entry to the syslog.conf file.

   The entry includes the location of the log file.

   # cat /etc/syslog.conf
   …
   audit.notice       /var/adm/auditlog

   Text logs should not be stored where the binary audit files are stored. The auditreduce command assumes that all files in an audit partition are binary audit files.

5. Create the log file.

   # touch /var/adm/auditlog

6. Refresh the configuration information for the syslog service.

   # svcadm refresh system/system-log

7. Regularly archive the syslog log files.

   The auditing service can generate extensive output. To manage the logs, see the logadm(1M) man page.

Example 30-5 Specifying Audit Classes for syslog Output

In the following example, the syslog utility collects a subset of the preselected audit classes.

# audit_control file
dir:/var/audit/host.1/files
dir:/var/audit/host.2/files
dir:/var/audit/localhost/files
flags:lo,ss
minfree:10
naflags:lo,na
plugin:name=audit_syslog.so.1; p_flags=-lo,-na,-ss

The flags and naflags entries instruct the system to collect all login/logout, nonattributable, and change of system state audit records in binary format. The plugin entry instructs the syslog utility to collect only failed logins, failed nonattributable events, and failed changes of system state.

Example 30-6 Putting syslog Audit Records on a Remote System

You can change the audit.notice entry in the syslog.conf file to point to a remote system. In this example, the name of the local system is example1. The remote system is remote1.

example1 # cat /etc/syslog.conf
…
audit.notice       @remote1

The audit.notice entry in the syslog.conf file on the remote1 system points to the log file.

remote1 # cat /etc/syslog.conf
…
audit.notice       /var/adm/auditlog

How to Change a User's Audit Characteristics

Definitions for each user are stored in the audit_user database. These definitions modify, for the specified user, the preselected classes in the audit_control file. The nsswitch.conf file determines if a local file or if a name service database is used. To calculate the user's final audit preselection mask, see Process Audit Characteristics.

1. Assume the Primary Administrator role, or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. (Optional) Save a backup copy of the audit_user database.

   # cp /etc/security/audit_user /etc/security/audit_user.orig

3. Add new entries to the audit_user database.

   In the local database, each entry has the following format:

   username:always-audit:never-audit

   username

   Selects the name of the user to be audited.

   always-audit

   Selects the list of audit classes that should always be audited for the specified user.

   never-audit

   Selects the list of audit classes that should never be audited for the specified user.

   You can specify multiple classes by separating the audit classes with commas.

   The audit_user entries are in effect at the user's next login.

Example 30-7 Changing Which Events Are Audited for One User

In this example, the audit_control file contains the preselected audit classes for the system:

# audit_control file
…
flags:lo,ss
minfree:10
naflags:lo,na

The audit_user file shows an exception. When the user jdoe uses a profile shell, that use is audited:

# audit_user file
jdoe:pf

The audit preselection mask for jdoe is a combination of the audit_user settings with the audit_control settings. The auditconfig -getaudit command shows the preselection mask for jdoe:

# auditconfig -getaudit
audit id = jdoe(1234567)
process preselection mask = ss,pf,lo(0x13000,0x13000)
terminal id (maj,min,host) = 242,511,example1(192.168.160.171)
audit session id = 2138517656

Example 30-8 Auditing Users Only, Not the System

In this example, the login and role activities of four users only are audited on this system. The audit_control file does not preselect audit classes for the system:

# audit_control file
…
flags:
minfree:10
naflags:

The audit_user file preselects two audit classes for four users:

# audit_user file
jdoe:lo,pf
kdoe:lo,pf
pdoe:lo,pf
sdoe:lo,pf

The following audit_control file protects the system from unwarranted intrusion. In combination with the audit_user file, this file protects the system more than the first audit_control file in this example.

# audit_control file
…
flags:
minfree:10
naflags:lo

How to Add an Audit Class

When you create your own audit class, you can place into it just those audit events that you want to audit for your site. When you add the class on one system, you should copy the change to all systems that are being audited.

1. Assume the Primary Administrator role, or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. (Optional) Save a backup copy of the audit_class file.

   # cp /etc/security/audit_class /etc/security/audit_class.orig

3. Add new entries to the audit_class file.

   Each entry has the following format:

   0xnumber:name:description

   0x

   Identifies number as hexadecimal.

   number

   Defines the unique audit class mask.

   name

   Defines the letter name of the audit class.

   description

   Defines the descriptive name of the audit class.

   The entry must be unique in the file. Do not use existing audit class masks.

Example 30-9 Creating a New Audit Class

This example creates a class to hold a small set of audit events. The added entry to the audit_class file is as follows:

0x01000000:pf:profile command

The entry creates a new audit class that is called pf. Example 30-10 populates the new audit class.

Troubleshooting

If you have customized the audit_class database, make sure that any modifications to audit_user are consistent with the new audit classes. Errors occur when the audit classes in audit_user are not a subset of the audit_class database.

How to Change an Audit Event's Class Membership

You might want to change an audit event's class membership to reduce the size of an existing audit class, or to place the event in a class of its own. When you reconfigure audit event-class mappings on one system, you should copy the change to all systems that are being audited.

1. Assume the Primary Administrator role, or become superuser.

   The Primary Administrator role includes the Primary Administrator profile. To create the role and assign the role to a user, see Chapter 2, Working With the Solaris Management Console (Tasks), in System Administration Guide: Basic Administration.

2. (Optional) Save a backup copy of the audit_event file.

   # cp /etc/security/audit_event /etc/security/audit_event.orig

3. Change the class to which particular events belong by changing the class-list of the events.

   Each entry has the following format:

   number:name:description:class-list

   number

   Is the audit event ID.

   name

   Is the name of the audit event.

   description

   Typically, the system call or executable that triggers the creation of an audit record.

   class-list

   Is a comma-separated list of audit classes.

Example 30-10 Mapping Existing Audit Events to a New Class

This example maps an existing audit event to the new class that was created in Example 30-9. In the audit_control file, the binary audit record captures successes and failures of events in the pf class. The syslog audit log contains only failures of events in the pf class.

# grep pf | /etc/security/audit_class
0x01000000:pf:profile command
# vi /etc/security/audit_event
6180:AUE_prof_cmd:profile command:ua,as,pf
# vi audit_control
...
flags:lo,pf
plugin:name=audit_syslog.so.1; p_flags=-lo,-pf

Example 30-11 Auditing the Use of setuid Programs

This example creates a class to hold events that monitor calls to the setuid and setgid programs. The audit_control entries audit all successful invocations of the events in the st class.

# vi /etc/security/audit_class
0x00000800:st:setuid class
# vi /etc/security/audit_event
26:AUE_SETGROUPS:setgroups(2):st
27:AUE_SETPGRP:setpgrp(2):st
40:AUE_SETREUID:setreuid(2):st
41:AUE_SETREGID:setregid(2):st
214:AUE_SETEGID:setegid(2):st
215:AUE_SETEUID:seteuid(2):st
# vi audit_control
...
flags:lo,+st
plugin:name=audit_syslog.so.1; p_flags=-lo,+st