Auditing a System

Auditing is set per system by the security administrator in the audit_control(4) file. This file on each system is read by the audit daemon. The audit_control file is located in the /etc/security directory.

A system–specific audit_control file is maintained on each system because the dir: lines, and perhaps the minfree: line are specific to the system. In a distributed system, the other lines should be identical.

You specify four kinds of information in four kinds of lines in the audit_control file:

• The audit flags line (flags:) contains the audit flags that define what classes of events are audited for all users on the system. The audit flags specified here are referred to as the system-wide audit flags or the system-wide audit preselection mask. Audit flags are separated by commas, with no spaces.

• The nonattributable flags line (naflags:) contains the audit flags that define what classes of events are audited when an action cannot be attributed to a specific user. The flags are separated by commas, with no spaces.

• The audit threshold line (minfree:) defines the minimum free-space level for all audit file systems. See Storing Audit Data.

  The minfree percentage must be greater than or equal to 0. The default is 20 percent.

• The directory definition lines (dir:) define which audit file systems and directories the system will use to store its audit trail files.

  There may be one or more directory definition lines. The order of the dir: lines is significant, because the auditd command opens audit files in the directories in the order specified (see the audit(1M) man page). The first audit directory specified is the primary audit directory for the system, the second is the secondary audit directory where the audit daemon puts audit trail files when the first one fills, and so forth.

The security administrator modifies the default audit_control file during the configuration process on each system.

After the audit_control file is configured, the system administrator on a distributed system distributes it to the other hosts. After any change in the file, the administrator runs audit -s on every system on the network to instruct the audit daemon to reread its audit_control file.

The audit -s command does not change the preselection mask for existing processes (see Process Preselection Mask). Use auditconfig, setaudit (see the getauid(2) man page), or auditon(2) for existing processes.

Dynamic controls refer to controls put in place by the administrator while processes are running. These persist only while the affected processes (and any of their children) exist, but will not continue in effect at the next login. Dynamic controls apply to one system at a time, since the audit command only applies locally.

Sample audit_control File

Following is a sample audit_control file for the system willet. willet uses two audit file systems on the audit server egret, and a third audit file system mounted from the audit administration server audubon, which is used to store audit records only when the audit file system on egret fills up or is unavailable. The minfree value of 20 percent specifies that the warning script (see the audit_warn(1M) man page) is run when the file systems are 80 percent filled and the audit data for the current system will be stored in the next available audit directory, if any. The flags specify that all logins and administrative operations are to be audited (whether or not they succeed), and that failures of all types except failures to create a file system object are to be audited.

flags:lo,ad,-all,^-fc
naflags:lo,nt
minfree:20
dir:/etc/security/audit/egret/files
dir:/etc/security/audit/egret.1/files
#
# Audit filesystem used when egret fills up
#
dir:/etc/security/audit/audubon

Successful events and failed events are treated separately, so a process can (for example) generate more audit records when an error occurs than when the event is successful.

Each process has two sets of one-bit flags for audit classes. One set controls whether the process is audited when an event in the class is requested successfully. The other set controls auditing when an event is requested but fails (for any reason). It is common for processes to be more heavily audited for failures than for successes, since this can be used to detect attempts at browsing and other types of attempts at violating system security.