File Token

The “file” token is used at the beginning and end of an audit log file to indicate when the audit log begins and ends. It includes a pathname so that, if concatenated together, original file boundaries are still observable, and gaps in the audit log can be identified. A “file” token can be created using au_to_file(3).

Header Token

The “header” token is used to mark the beginning of a complete audit record, and includes the length of the total record in bytes, a version number for the record layout, the event type and subtype, and the time at which the event occurred. A 32-bit “header” token can be created using au_to_header32(3); a 64-bit “header” token can be created using au_to_header64(3).

Expanded Header Token

The “expanded header” token is an expanded version of the “header” token, with the addition of a machine IPv4 or IPv6 address. A 32-bit extended “header” token can be created using au_to_header32_ex(3); a 64-bit extended “header” token can be created using au_to_header64_ex(3).

Trailer Token

The “trailer” terminates a BSM audit record, and contains a magic number, AUT_TRAILER_MAGIC and length that can be used to validate that the record was read properly. A “trailer” token can be created using au_to_trailer(3).

Identity Token

The “identity” token contains information about the process that triggered the audit record to be created. An “identity” token can be created using au_to_identity(3).

Arbitrary Data Token

The “arbitrary data” token contains a byte stream of opaque (untyped) data. The size of the data is calculated as the size of each unit of data multipled by the number of units of data. A “How to print” field is present to specify how to print the data, but interpretation of that field is not currently defined. An “arbitrary data” token can be created using au_to_data(3).

in_addr Token

The “in_addr” token holds a network byte order IPv4 address. An “in_addr” token can be created using au_to_in_addr(3) for an IPv4 address.

Expanded in_addr Token

The “in_addr_ex” token holds a network byte order IPv4 or IPv6 address. An “in_addr_ex” token can be created using au_to_in_addr_ex(3) for an IPv6 address.

See the BUGS section for information on the storage of this token.

ip Token

The “ip” token contains an IP packet header in network byte order. An “ip” token can be created using au_to_ip(3).

iport Token

The “iport” token stores an IP port number in network byte order. An “iport” token can be created using au_to_iport(3).

Path Token

The “path” token contains a pathname. A “path” token can be created using au_to_path(3).

path_attr Token

The “path_attr” token contains a set of NUL-terminated path names. The libbsm(3) API cannot currently create a “path_attr” token.

Process Token

The “process” token contains a description of the security properties of a process involved as the target of an auditable event, such as the destination for signal delivery. It should not be confused with the “subject” token, which describes the subject performing an auditable event. This includes both the traditional UNIX security properties, such as user IDs and group IDs, but also audit information such as the audit user ID and session. A “process” token can be created using au_to_process32(3) or au_to_process64(3).

Expanded Process Token

The “expanded process” token contains the contents of the “process” token, with the addition of a machine address type and variable length address storage capable of containing IPv6 addresses. An “expanded process” token can be created using au_to_process32_ex(3) or au_to_process64_ex(3).

Return Token

The “return” token contains a system call or library function return condition, including return value and error number associated with the global variable errno. A “return” token can be created using au_to_return32(3) or au_to_return64(3).

Subject Token

The “subject” token contains information on the subject performing the operation described by an audit record, and includes similar information to that found in the “process” and “expanded process” tokens. However, those tokens are used where the process being described is the target of the operation, not the authorizing party. A “subject” token can be created using au_to_subject32(3) and au_to_subject64(3).

Expanded Subject Token

The “expanded subject” token consists of the same elements as the “subject” token, with the addition of type/length and variable size machine address information in the terminal ID. An “expanded subject” token can be created using au_to_subject32_ex(3) or au_to_subject64_ex(3).

System V IPC Token

The “System V IPC” token contains the System V IPC message handle, semaphore handle or shared memory handle. A System V IPC token may be created using +.Xr au_to_ipc 3 .

Text Token

The “text” token contains a single NUL-terminated text string. A “text” token may be created using au_to_text(3).

Attribute Token

The “attribute” token describes the attributes of a file associated with the audit event. As files may be identified by 0, 1, or many path names, a path name is not included with the attribute block for a file; optional “path” tokens may also be present in an audit record indicating which path, if any, was used to reach the object. An “attribute” token can be created using au_to_attr32(3) or au_to_attr64(3).

Groups Token

The “groups” token contains a list of group IDs associated with the audit event. A “groups” token can be created using au_to_groups(3).

System V IPC Permission Token

The “System V IPC permission” token contains a System V IPC access permissions. A System V IPC permission token may be created using au_to_ipc_perm(3).

Arg Token

The “arg” token contains informations about arguments of the system call. Depending on the size of the desired argument value, an Arg token may be created using au_to_arg32(3) or au_to_arg64(3).

exec_args Token

The “exec_args” token contains informations about arguements of the exec() system call. An exec_args token may be created using au_to_exec_args(3).

exec_env Token

The “exec_env” token contains current eviroment variables to an exec() system call. An exec_args token may be created using au_to_exec_env(3).

Exit Token

The “exit” token contains process exit/return code information. An “exit” token can be created using au_to_exit(3).

Socket Token

The “socket” token contains information about UNIX domain and Internet sockets. Each token has four or eight fields. Depending on the type of socket, a socket token may be created using au_to_sock_unix(3), au_to_sock_inet32(3) or au_to_sock_inet128(3).

Expanded Socket Token

The “expanded socket” token contains information about IPv4 and IPv6 sockets. A “expanded socket” token can be created using au_to_socket_ex(3).

Seq Token

The “seq” token contains a unique and monotonically increasing audit event sequence ID. Due to the limited range of 32 bits, serial number arithmetic and caution should be used when comparing sequence numbers.

privilege Token

The “privilege” token ...

Use-of-auth Token

The “use-of-auth” token ...

Command Token

The “command” token ...

ACL Token

The “ACL” token ...

Zonename Token

The “zonename” token holds a NUL-terminated string with the name of the zone or jail from which the record originated. A token can be created using au_to_zonename(3).