test

Trusted Solaris Audit Administration

Audit Record Format

Audit files consist of self-contained audit records of user-level and kernel-level events that have been preselected for auditing by the security administrator. An audit record consists of a sequence of audit tokens, each of which describes an attribute of the event being audited. Each auditable event in the system generates a particular type of audit record. The audit record for each event has certain tokens within the record that describe the event. An audit record does not describe the audit event class to which the event belongs; that mapping is determined by an external table, the /etc/security/audit_event file.

Each audit token starts with a one-byte token type, followed by one or more data elements in an order determined by the type. The different audit records are distinguished by event type and different sets of tokens within the record. Some tokens, such as the text token, contain only a single data element, while others, such as the process token, contain several (including the audit user ID, real user ID, and effective user ID).

Audit records are stored and manipulated in binary form; however, the byte order and size of data is predetermined to simplify compatibility between different workstations.

"Audit Token Structure", gives a detailed description of each data element in each token and shows sample output. "Audit Records" lists all the audit records generated by Trusted Solaris 7 auditing. The records are listed alphabetically by kernel event and by user event. A cross-reference table to the audit records is found in Appendix A, Event-to-Class Mappings.

Order of Audit Tokens

Each audit record begins with a header token and ends (optionally) with a trailer token. One or more tokens between the header and trailer describe the event. For user-level and kernel events, the tokens describe the process that performed the event, the objects on which it was performed, and the objects' attributes, such as the owner or mode.

For example, the AUE_LSTAT kernel event, whose audit record is described in Table B-70, has the following tokens:

If the trail policy has been turned on using the auditconfig command, the trailer token appears in the audit record after the return token.

Human-Readable Audit Record Format

This section provides examples of audit records in text format. Audit records are stored in binary format. Running the binary records through the praudit command produces text output, which can be sent to standard output, a printer, or a scripting program to produce reports. For a complete description of praudit, see the praudit(1M) man page. For an example of a scripting program, see "To Perform Selections Using a praudit Script".

Reading an Audit Token

The following examples of a header token show the form that praudit produces by default. Examples are also provided of raw (-r) and short (-s) options.

Every audit record begins with a header token. The header token gives information common to all audit records. When displayed by praudit in default format, a header token looks like the following example from ioctl(): 

header,240,1,ioctl(2),,Tue Sept  7 16:11:44 1999, + 270000 msec

The fields are:

Using praudit -s, the event description (ioctl(2) in the default praudit example above) is replaced with the event name (AUE_IOCTL), like this:

header,240,1,AUE_IOCTL,,Tue Sept 7 16:11:44 1999, + 270000 msec

Using praudit -r, all fields are displayed as numbers (that may be decimal, octal, or hex), where 20 is the header token ID and 158 is the event number for this event. 

20,240,1,158,,699754304, + 270000 msec

Note that praudit displays the time to millisecond resolution.

Reading an Audit Record

Every audit record contains at least the header token and one other token. For example, the audit record for the audit event AUE_login contains five tokens. See Table B-247 for a full description of its audit record format.

When displayed by praudit in default format, the audit record for AUE_login looks like this, one token per line: 

header,90,3,login - local,,Tue Jul 8 15:12:01 1997, +520002000 msec,
text,emily
text,successful login
subject,emily,emily,staff,emily,staff,14094,14094,0 0 willet,
return,success,0
sequence,17
trailer,90

The tokens are:

When this audit file collected records, the audit policy tokens sequence and trailer were turned on, so all audit records including this one contain the following tokens:

Note the following features in the audit record:

Because each audit record contains an audit ID that identifies the user who generated the event, and because audit records are self-contained, you can look at individual audit records and get meaningful information without looking back through the audit trail.

The Trusted Solaris 7 audit records contain all the relevant information about an event and do not require you to refer to other audit records to interpret what occurred. For example, an audit record describing a file event contains the file's full path name starting at the root directory and a time and date stamp of the file's opening or closing.

Note -

You should archive system administration files with audit file archives. Information that is referred to in the audit trail but changes as site personnel and equipment change, such as users and their UIDs, affects your ability to interpret records.

Using praudit -l, the audit record displays on one line, like this: 

header,90,3,login - local,,Tue Jul 8 15:12:01 1997, +520002000 msec,text,emily,text,successful
login,subject,emily,emily, staff,emily,staff,14094,14094,0 0 willet,return,success,0,
sequence,17,trailer,90

Using praudit -r the audit record displays like this: 

20,90,3,6152,0x0000,872028721,520002000
40,emily
40,successful login
36,6001,6001,10,6001,10,14094,14094,0 0 129.150.110.2
39,0,0
47,17
19,90