Audit Flags

Audit flags indicate classes of events to audit. Machine-wide defaults for auditing are specified for all users on each machine by flags in the audit_control file, which is described in "The audit_control File".

You can modify what is audited for individual users by putting audit flags in a user's entry in the audit_user file. The audit flags are also used as arguments to the auditconfig command (see the auditconfig(1M) man page).

Definitions of Audit Flags

The following table shows each predefined audit class with the audit flag (which is the short name that stands for the class), the long name, and a short description. You use these audit flags in the auditing configuration files to specify which classes of events to audit. You can define new classes and rename existing classes by modifying the audit_class file (see the audit_class(4) man page).

Table 25-2 Audit Flags

Short Name	Long Name	Short Description
`no`	`no_class`	Null value for turning off event preselection
`fr`	`file_read`	Read of data, open for reading
`fw`	`file_write`	Write of data, open for writing
`fa`	`file_attr_acc`	Access of object attributes: `stat`, `pathconf`
`fm`	`file_attr_mod`	Change of object attributes: `chown`, `flock`
`fc`	`file_creation`	Creation of object
`fd`	`file_deletion`	Deletion of object
`cl`	`file_close`	`close` system call
`pc`	`process`	Process operations: `fork`, `exec`, `exit`
`nt`	`network`	Network events: `bind`, `connect`, `accept`
`ip`	`ipc`	System V IPC operations
`na`	`non_attrib`	Nonattributable events
`ad`	`administrative`	Administrative actions
`lo`	`login_logout`	Login and logout events
`ap`	`application`	Application-defined event
`io`	`ioctl`	`ioctl` system call
`ex`	`exec`	Program execution
`ot`	`other`	Miscellaneous
`all`	`all`	All flags set

Audit Flag Syntax

The prefixes determine whether a class of events is audited whether it succeeds or fails, or only if it succeeds, or only if it fails. Here is the format of the audit flag:

prefixflag

The following table shows prefixes that specify whether the audit class is audited for success or failure, or both.

Table 25-3 Prefixes Used in Audit Flags

Prefix	Definition
`none`	Audit for both success and failure
`+`	Audit for success only
`-`	Audit for failure only

For example, the audit flag lo (without any prefix) means that auditing should occur for "all successful attempts to log in and log out, and all failed attempts to log in." You cannot fail an attempt to log out. As another example, the -all flag means that auditing should occur only for all failed attempts of any kind. The +all flag means that auditing should only occur for all successful attempts of any kind.

Caution - The -all flag can generate large amounts of data and fill up audit file systems quickly. Use the -all flag only if you have extraordinary reasons to audit all activities.

Prefixes to Modify Audit Flags

Use the following prefixes in any of three ways:

In the flags line in the audit_control file to modify already specified flags
In flags field in the user's entry in the audit_user file
With arguments to the auditconfig command

See the auditconfig(1M) man page.

The prefixes in the following table, along with the short names of audit classes, turn on or turn off previously specified audit classes.

Table 25-4 Prefixes Used to Modify Already-Specified Audit Flags

Prefix	Definition
`^-`	Turn off for failed attempts
`^+`	Turn off for successful attempts
`^`	Turn off for both failed and successful attempts

The ^- prefix is used in the flags line in the following example from an audit_control file.

In the following example, the lo and ad flags specify that all logins and administrative operations are to be audited when they succeed and when they fail. The -all means audit "all failed events." Because the ^- prefix means "turn off auditing for the specified class for failed attempts," the ^-fc flag modifies the previous flag that specified the auditing of all failed events. The two fields together mean: "audit all failed events, except for failed attempts to create file system objects."

flags:lo,ad,-all,^-fc

Audit Policies

Audit policies determine if additional tokens or information is added to the audit trail. Each policy is defined in "Determining Which Audit Policies to Use".

Process Audit Characteristics

The following audit characteristics are set at initial login:

Process preselection mask - When a user logs in, the login command combines the machine-wide audit flags from the audit_control file with the user-specific audit flags (if any) from the audit_user file, to establish the process preselection mask for the user's processes. The process preselection mask specifies whether events in each audit event class are to generate audit records.

The algorithm for obtaining the process preselection mask is as follows: the audit flags from the flags: line in the audit_control file are added to the flags from the always-audit field in the user's entry in the audit_user file. Then, the flags from the never-audit field from the user's entry in the audit_user file are subtracted from the total, as follows:
user's process preselection mask = (flags: line + always audit flags) - never audit flags
Audit ID - A process also acquires its audit ID when the user logs in. This audit ID is inherited by all child processes that were started by the user's initial process. The audit ID helps enforce accountability. Even after a user becomes root, the audit ID remains the same. The audit ID that is saved in each audit record always allows you to trace actions back to the original user who had logged in.
Audit Session ID - The audit session ID is assigned at login and inherited by all descendant processes.
Terminal ID (port ID, machine ID) -The terminal ID consists of the host name and the Internet address, followed by a unique number that identifies the physical device on which the user logged in. Most often, the login is through the console and the number that corresponds to the console device is 0.

Audit Trail

The audit trail is created by the audit daemon (see the auditd(1M) man page). The audit daemon starts on each machine when the machine is brought up. After the auditd daemon starts at boot time, it is responsible for collecting the audit trail data and writing the audit records into audit files, which are also called audit log files. For a description of the file format, see the audit.log(4) man page.

Even though you can physically locate audit directories within other file systems that are not dedicated to auditing, do not do so except for directories of last resort. Directories of last resort are directories where audit files are written only when there is no other suitable directory available.

There is one other scenario where locating audit directories outside of dedicated audit file systems could be acceptable. You might do so in a software development environment where auditing is optional, and where it is more important to make full use of disk space than to keep an audit trail. Putting audit directories within other file systems is not acceptable in a security-conscious production environment.

You should also consider the following:

A host should have at least one local audit directory, which it can use as a directory of last resort if the host is unable to communicate with the audit server.
Mount audit directories with the read-write (rw) option. When you mount audit directories remotely (using NFS software), also use the intr and noac options.
List the audit file systems on the audit server where they reside. The export list should include all machines in the configuration.


25. BSM Services Reference Audit Files The `audit_warn` Script