Audit Service Files

Auditing uses the following files:

• The /etc/system File

• The audit_class File

• The audit_control File

• The audit_data File

• The audit_event File

• The audit_startup Script

• The audit_user File

• The audit_warn Script

The /etc/system File

The /etc/system file contains commands that the kernel reads during initialization to customize the system operations. The bsmconv and bsmunconv shell scripts, which are used to activate and deactivate auditing, modify the /etc/system file. The bsmconv shell script adds the following line to the /etc/system file:

set c2audit:audit_load=1

The set c2audit:audit_load=1 command causes the auditing module, a kernel module, to be loaded when the system is booted. The bsmunconv shell script disables auditing when the system is rebooted. The command removes the c2audit line from the /etc/system file.

The audit_class File

The /etc/security/audit_class file contains definitions of the existing audit classes. Audit classes are groups of audit events. Each class has an associated audit flag, which is the short name that stands for the class. You use the short name in the audit_control file to preselect the classes whose events you want to audit. The flags accept prefixes for finer–grained selection. See Audit Flag Syntax for more information.

The root user, or an administrator in an equivalent role, can modify the definitions of audit classes. This administrator can define new audit classes, rename existing classes, or otherwise change existing classes by editing the audit_class file in a text editor. See the audit_class(4) man page for more information. For descriptions of the audit flags, see Definitions of Audit Flags.

The audit_control File

An /etc/security/audit_control file on each machine is read by the audit daemon. See the audit_control(4) man page. The audit_control file is located in the /etc/security directory. Each machine has its own local audit_control file. The file enables every machine to mount their audit file systems from different locations or in a different order. For example, the primary audit file system for machineA might be the secondary audit file system for machineB.

You specify four kinds of information in the audit_control file. Each line of information begins with a keyword.

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

• The nonattributable flags line begins with naflags:. The line contains the audit flags that preselect which 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 begins with minfree:. The line defines the minimum free-space level for all audit file systems. The minfree percentage must be greater than or equal to 0. The default is 20 percent. When an audit file system is 80 percent filled, the audit data is then stored in the next available audit directory. See the audit_warn(1M) man page.

• The directory definition lines begin with dir:. Each line defines an audit file system and directory that the machine uses to store its audit log files. You can define one or more directory definition lines. The order of the dir: lines is significant. The auditd daemon creates audit files in the directories in the specified order. The first directory is the primary audit directory for the machine. The second directory is the secondary audit directory where the audit daemon creates audit trail files when the first directory becomes full, and so forth. See the audit(1M) man page.

An audit_control file is created during the configuration process on each machine.

When you make changes to the audit_control file, you then run the audit -s command to instruct the audit daemon to reread the file.

The audit -s command does not change the preselection mask for existing processes. Use auditconfig, setaudit, or auditon for existing processes. See the getaudit(2) and auditconfig(1M) man pages for more information.

Sample audit_control File

The following is a sample audit_control file for the machine dopey. dopey uses two audit file systems on the audit server blinken, and a third audit file system that is mounted from the second audit server winken. The third file system is used only when the audit file systems on blinken become full or unavailable. The minfree value of 20 percent specifies that the warning script is run when the file systems are 80 percent filled. The flags specify that logins and administrative operations are to be audited. The operations are audited for success and for failure. Failures of all types, except failures to create a file system object, are to be audited. Non-attributable events are also audited.

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

The audit_data File

When the auditd daemon starts on each machine, it creates the file /etc/security/audit_data. The format of the file consists of a single entry with the two fields separated by a colon. See the audit_data(4) man page. The first field is the audit daemon's process ID. The second field is the path name of the audit file to which the audit daemon is currently writing audit records. Here is an example:

# cat /etc/security/audit_data
116:/etc/security/audit/blinken.1/files/19990320100002.not_terminated.dopey

The audit_event File

The /etc/security/audit_event file contains the default event-to-class mappings.You can edit this file to change the class mappings. However, if you do so, you must reboot the system or run auditconfig -conf to read the changed mappings into the kernel. See the audit_event(4) man page.

The audit_startup Script

The /etc/security/audit_startup script automatically starts the audit daemon when the system enters multiuser mode. The script is invoked as part of the startup sequence, just prior to the execution of the audit daemon. See the audit_startup(1M) man page for more information.

A default audit_startup script that automatically configures the event-to-class mappings and sets the audit policies. The script is created during the BSM package installation.

The audit_user File

To audit some users differently from others, you can edit the /etc/security/audit_user file to add audit flags for individual users. If specified, these flags are combined with the system-wide flags in the audit_control file to determine which classes of events to audit for that user. The flags that you add to the user's entry in the audit_user file modify the defaults from the audit_control file in two ways:

• By specifying event classes that are always to be audited for this user

• By specifying event classes that are never to be audited for this user

Each user entry in the audit_user file contains three fields.

• The username field

• The always-audit field

• The never-audit field

The audit fields are processed in sequence. The always-audit field turns on the auditing of the classes in that field. The never-audit field turns off the auditing of the classes in that field.

Avoid the common mistake of leaving the all audit flag in the never-audit field. This mistake causes all auditing to be turned off for that user, which overrides the flags that are set in the always-audit field. The flag also overrides machine-wide audit flags set in the audit_control file.

The never-audit flags for a user override the system defaults. You might not want to overrride system defaults. For example, suppose you want to audit everything for user tamiko for except for successful reads of file system objects. This strategy audits almost everything for a user. However, the strategy generates about three-quarters of the audit data that would be produced if all data reads were audited. You also want to apply the system defaults to tamiko. Here are two possible audit_user entries:

The correct entry:

tamiko:all,^+fr:

The incorrect entry:

tamiko:all:+fr

The first example means, “always audit everything except for successful file-reads.” The second example means, “always audit everything, but never audit successful file-reads.” The second example is incorrect because the never-audit field would override the system defaults. The first example achieves the desired effect: the always-audit flags include the exception to the all flag. Since no flag is in the never-audit field, the system defaults from the audit_control file are not overridden here.

Successful events and failed events are treated separately. A process could generate more audit records when an error occurs than when an event is successful.

The audit_warn Script

Whenever the audit daemon encounters an unusual condition while writing audit records, it invokes the /etc/security/audit_warn script. See the audit_warn(1M) man page. You can customize this script for your site to warn of conditions that might require manual intervention. Or, you could specify how to handle those conditions automatically. For all error conditions, audit_warn writes a message to the console. audit_warn also sends a message to the audit_warn mail alias. You should set up this alias when you enable auditing.

When audit daemon detects the following conditions, it invokes the audit_warn script.

• An audit directory has become more full than the minfree value allows. The minfree value or soft limit is a percentage of the space available on an audit file system.

  The audit_warn script is invoked with the string soft and the name of the directory whose available space has gone below the minimum value. The audit daemon switches automatically to the next suitable directory. The daemon writes the audit files in this new directory until the directory reaches its minfree limit. The audit daemon then goes to each remaining directory in the order that is listed in the audit_control file. The daemon writes audit records until each directory is at its minfree limit.

• All the audit directories have reached the minfree threshold.

  The audit_warn script is invoked with the string allsoft. A message is written to the console. Mail is also sent to the audit_warn alias.

  When all audit directories that are listed in the audit_control file have reached their minfree threshold, the audit daemon switches back to the first directory. The daemon writes audit records until the directory becomes completely full.

• An audit directory has become completely full with no space remaining.

  The audit_warn script is invoked with the string hard and the name of the directory. A message is written to the console. Mail is also sent to the audit_warn alias.

  The audit daemon switches automatically to the next suitable directory with any space available. The audit daemon goes to each remaining directory in the order that is listed in the audit_control file. The daemon writes audit records until each directory is full.

• All the audit directories are completely full. The audit_warn script is invoked with the string allhard as an argument.

  In the default configuration, a message is written to the console. Mail is also sent to the audit_warn alias. The processes that generate audit records are suspended. The audit daemon goes into a loop, waiting for space to become available, and resumes processing audit records when that happens. While audit records are not being processed, no auditable activities occur. Every process that attempts to generate an audit record is suspended. For this reason, you should set up a separate audit administration account that could operate without any auditing enabled. Then, you could continue operations without being suspended.

• An internal error occurs. Possible internal errors include the following:

  • ebusy – Another audit daemon process is already running

  • tmpfile – A temporary file cannot be used

  • auditsvc – The auditsvc() system call fails

  • postsigterm – A signal was received during auditing shutdown

  Mail is sent to the audit_warn alias.

• A problem is discovered with the syntax of the audit_control file. By default, a message is sent to the console. Mail is also sent to the audit_warn alias.