Audit Trail

The audit trail is created by the audit daemon. 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. See also the auditd(1M) man page.

Even though you can physically locate audit directories within 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. To make full use of disk space might be more important than to keep an audit trail. However, in a security-conscious environment, audit directories within other file systems is not acceptable.

You should also consider the following factors.

• A host should have at least one local audit directory. The local directory can be used 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, 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.

Naming Conventions for Audit Files

Each audit file is a self-contained collection of records. The file's name identifies the time span during which the records were generated and the machine that generated them.

Audit File Naming

Audit files that are complete have names of the following form:

start-time.finish-time.machine 

where

• start-time - Is the time that the first audit record in the audit file was generated.

• finish-time - Is the time that the last record was written to the file.

• machine - Is the name of the machine that generated the file.

For an example of these names, see Example of a Closed Audit File Name.

An audit log file that is still active has a name of the following form:

start-time.not_terminated.machine

How Audit File Names Are Used

The time stamps in file names are used by the auditreduce command to locate records within a specific time range. These time stamps are important because there can be a month's accumulation or more of audit files online. To search all the files for records that were generated in the last 24 hours would be unacceptably expensive.

Time-Stamp Format and Interpretation

The start-time and end-time are timestamps with one-second resolution. They are specified in Greenwich Mean Time (GMT). The format is four digits for the year, followed by two digits for each month, day, hour, minute, and second, as follows:

YYYYMMDDHHMMSS

The timestamps are in GMT to ensure that they sort in proper order even across a daylight savings time boundary. Because they are in GMT, the date and hour must be translated to the current time zone to be meaningful. Beware of this point whenever you manipulate these files with standard file commands rather than with the auditreduce command.

Example of a File Name for a Still-Active File

The format of a file name of a still-active file is as follows:

YYYYMMDDHHMMSS.not_terminated.machine

Here is an example:

19990327225243.not_terminated.dopey

The audit log files are named by the beginning date. So, in the example above the audit file was created in 1999, on March 27, at 10:52:43 p.m, GMT. The not_terminated in the file name means either that the file is still active or that the auditd daemon was unexpectedly interrupted. The name dopey at the end is the host name of the machine whose audit data is being collected.

Example of a Closed Audit File Name

The format of the name of a closed audit log file is as follows:

YYYYMMDDHHMMSS.YYYYMMDDHHMMSS.hostname

Here is an example:

19990320005243.19900327225351.dopey

In this example, the audit log file was created in 1999, on March 20, at 12:52:43 a.m., GMT. The file was closed March 27, at 10:53:51 p.m., GMT. The name dopey at the end is the host name of the machine whose audit data was collected.

Whenever auditd is unexpectedly interrupted, the audit file that is open at the time retains the not_terminated file name designation. For example, when a machine is writing to a remotely mounted audit file, the file server can become inaccessible. When the mounted audit file cannot be reached, the not_terminated designation remains in the file's name. When service is restored, the audit daemon opens a new audit file and keeps the old audit file name intact.

Audit Record Structure

An audit record is a sequence of audit tokens. Each audit token contains event information such as user ID, time, and date. A header token begins an audit record, and an optional trailer token concludes the record. Other audit tokens contain information relevant to the auditable event. The following figure shows a typical audit record.

Figure 23-3 Typical Audit Record Structure

Audit Token Formats

Each token has a token type identifier followed by data that is specific to the token. Each token type has its own format. The following table shows the token names with a description of each token.

Table 23-4 Audit Tokens for the Basic Security Module

An audit record always contains a header token. The header token indicates where the audit record begins in the audit trail. Every audit record contains a subject token, except for audit records from some nonattributable events. In the case of attributable events, these two tokens refer to the values of the process that caused the event. In the case of asynchronous events, the process tokens refer to the system.