More About the 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, and 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 file name time stamps are used by the auditreduce command to locate files that contain records for the specific time range that has been requested. These time stamps are important because there can be a month's accumulation or more of audit files online, and searching them all 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 will 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. Also, when a machine is writing to a remotely mounted audit file and the file server crashes or becomes inaccessible, the not_terminated designation remains in the current file's name. 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 25-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 25-5 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.

acl Token

The acl token records information about Access Control Lists. This token consists of four fixed fields. The fixed fields are:

• a token ID that identifies this token as an acl token

• a field that specifies the ACL type

• an ACL ID field

• a field that lists the permissions associated with this ACL

The praudit command displays the acl token as follows:

acl,tpanero,staff,0755

The acl token format is as follows:

Figure 25-4 acl Token Format

arbitrary Token

The arbitrary token encapsulates data for the audit trail. This token consists of four fixed fields and an array of data. The fixed fields are as follows:

• a token ID that identifies this token as an arbitrary token

• a suggested format field (for example, hexadecimal)

• a size field that specifies the size of the data that is encapsulated (for example, short)

• a count field that provides the number of following items

The remainder of the token is composed of one or more items of the specified type. The praudit command displays the arbitrary token as follows:

arbitrary,decimal,int,1
42

The format of arbitrary token is as follows:

Figure 25-5 arbitrary Token Format

The following table shows the possible values of the print format field. Table 25-6.

Table 25-6 Values for the arbitrary Token's Print Format Field

The following table shows the possible values of the item size field.

Table 25-7 Values for the arbitrary Token's Item Size Field