test

SunSHIELD Basic Security Module Guide

Audit Record Format

A Solaris BSM audit record consists of a sequence of audit tokens, each of which describes an attribute of the system.

Appendix A, Audit Record Descriptions gives a detailed description of each audit token. The appendix also lists all the audit records generated by Solaris BSM auditing. The definitions are sorted in order of the short descriptions, and a cross-reference table translates event names to event descriptions.

Binary Format

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

Audit Event Type

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.

Audit Token Types

Each 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).

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' tokens, such as the owner or mode.

Each user-level and kernel event typically has at least the following tokens:

Many events also include a trailer token, but it is optional.

Human-Readable Audit Record Format

This section shows each audit record format as it appears in the output produced by the praudit command. This section also gives a short description of each audit token. For a complete description of each field in each token, see Appendix A, Audit Record Descriptions.

The following token examples show the form that praudit produces by default. Examples are also provided of raw (-r) and short (-s) options. When praudit displays an audit token, it begins with the token type, followed by the data from the token. Each data field from the token is separated from other fields by a comma. However, if a field (such as a path name) contains a comma, this cannot be distinguished from a field-separating comma. Use a different field separator or the output will contain commas. The token type is displayed by default as a name, like header, or in -r format as a decimal number.

The individual tokens are described in the following order:

header Token

Every audit record begins with a header token. The header token gives information common to all audit records. The fields are:

When displayed by praudit in default format, a header token looks like the following example from ioctl: 


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

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,es,Tue Sept 1 16:11:44 1992, + 270000 msec

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


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

Note that praudit displays the time to millisecond resolution.

trailer Token

This token marks the end of an audit record and allows backward seeks of the audit trail. The fields are:

A trailer token is displayed by praudit as follows: 


trailer,136

arbitrary Token

This token encapsulates data for the audit trail. The item array may have a number of items. The fields are:

An arbitrary token is displayed by praudit as follows: 


arbitrary,decimal,int,1
42

arg Token

This token contains system call argument information. A 32-bit integer system call argument is allowed in an audit record. The fields are:

An arg token is displayed by praudit as follows: 


argument,1,0x00000000,addr

attr Token

This token contains information from the file vnode. The attr token is usually produced during path searches and accompanies a path token, but is not included in the event of a path-search error. The fields are:

An attr token is displayed by praudit as follows: 


attribute,100555,root,staff,1805,13871,-4288

exit Token

An exit token records the exit status of a program. The fields are:

An exit token is displayed by praudit as follows: 


exit,Error 0,0

file Token

This token is generated by the audit daemon to mark the beginning of a new audit trail file and the end of an old file as the old file is deactivated. The audit record containing this token links together successive audit files into one audit trail. The fields are:

A file token is displayed by praudit as follows: 


file,Tue Sep  1 13:32:42 1992, + 79249 msec,
	/baudit/localhost/files/19920901202558.19920901203241.quisp

groups Token

A groups token records the groups entries from a process's credential. The fields are:

A groups token is displayed by praudit as follows: 


group,staff,wheel,daemon,kmem,bin,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1

in_addr Token

An in_addr token gives a machine Internet Protocol address. The fields are:

An in_addr token is displayed by praudit as follows: 


ip addr,129.150.113.7

ip Token

The ip token contains a copy of an Internet Protocol header. The fields are:

An ip token is displayed by praudit as follows: 


ip address,0.0.0.0

ipc Token

This token contains the System V IPC message/semaphore/shared-memory handle used by a caller to identify a particular IPC object. The fields are:

An ipc token is displayed by praudit as follows: 


IPC,msg,3

ipc_perm Token

An ipc_perm token contains a copy of the System V IPC access information. Audit records for shared memory, semaphore, and message IPCs have this token added. The fields are:

An ipc_perm token is displayed by praudit as follows: 


IPC perm,root,wheel,root,wheel,0,0,0x00000000

iport Token

This token contains a TCP (or UDP) address. The fields are:

An iport token is displayed by praudit as follows: 


ip port,0xf6d6

opaque Token

The opaque token contains unformatted data as a sequence of bytes. The fields are:

An opaque token is displayed by praudit as follows: 


opaque,12,0x4f5041515545204441544100

path Token

A path token contains access path information for an object. The fields are:

A path token is displayed by praudit as follows: 


path,/an/anchored/path/name/to/test/auditwrite/AW_PATH

process Token

The process token contains information describing a process. The fields are:

A process token is displayed by praudit as follows: 


process,root,root,wheel,root,wheel,0,0,0,0.0.0.0

return Token

A return token gives the return status of the system call and the process return value. This token is always returned as part of kernel-generated audit records for system calls. The fields are:

A return token is displayed by praudit as follows: 


return,success,0

seq Token

This token is optional and contains an increasing sequence number used for debugging. The token is added to each audit record when the seq policy is active. The fields are:

A seq token is displayed by praudit as follows: 


sequence,1292

socket Token

A socket token describes an Internet socket. The fields are:

A socket token is displayed by praudit as follows: 


socket,0x0000,0x0000,0.0.0.0,0x0000,0.0.0.0

subject Token

This token describes a subject (process). The fields are:

A subject token is displayed by praudit as follows: 


subject,cjc,cjc,staff,cjc,staff,424,223,0 0 quisp

text Token

A text token contains a text string. The fields are:

A text token is displayed by praudit as follows: 


text,aw_test_token