The subject token is always returned as part of kernel-generated audit records for system calls. The praudit command displays the subject token as follows:

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

The audit ID, user ID, group ID, process ID, and session ID are long instead of short.

Note - The subject token fields for the session ID, the real user ID, or the real group ID might be unavailable. The value is then set to -1.

Any token that contains a terminal ID has several variations. The praudit command hides these variations on output of the terminal ID so that they all appear the same. This field is handled the same way for any token that contains it. The terminal ID is either an IP address and port number, or a device ID, such as the serial port that is connected to a modem, in which case it is zero. The terminal ID is specified in one of several formats:

For device numbers:

• 32-bit applications: 4-byte device number, 4-bytes unused

• 64-bit applications: 8-byte device number, 4-bytes unused

For port numbers in the Solaris 7 release or earlier releases:

• 32-bit applications: 4-byte port number, 4-byte IP address

• 64-bit applications: 8-byte port number, 4-byte IP address

For port numbers in the Solaris 8 or 9 releases:

• 32-bit with IPV4: 4-byte port number, 4-byte IP type, 4-byte IP address

• 32-bit with IPV6: 4-byte port number, 4-byte IP type, 16-byte IP address

• 64-bit with IPV4: 8-byte port number, 4-byte IP type, 4-byte IP address

• 64-bit with IPV6: 8-byte port number, 4-byte IP type, 16-byte IP address

The following figure shows the format of the subject token.

Figure 25-26 subject Token Format

text Token

The text token contains a text string. This token has three fields:

• a token ID that identifies this token as a text token

• the length of the text string

• the text string itself

The praudit command displays the text token as follows:

text,aw_test_token

The following figure shows the format of a text token.

Figure 25-27 text Token Format

trailer Token

The two tokens, header and trailer, are special in that they distinguish the end points of an audit record and bracket all the other tokens. A header token begins an audit record. A trailer token ends an audit record. The trailer token is an optional token and is added as the last token of each record only when the trail audit policy has been set.

The trailer token supports backward seeks of the audit trail. The trailer token has three fields:

• a token ID that identifies this token as a trailer token

• a pad number to aid in marking the end of the record

• the total number of characters in the audit record, including both the header and trailer tokens

The praudit command displays the trailer token as follows:

trailer,136

The following figure shows the format of a trailer token.

Figure 25-28 trailer Token Format

The audit trail analysis software ensures that each record contains both the header and trailer tokens. In the case of a write error, as when a file system becomes full, an audit record can be incomplete and truncated. The auditsvc() system call, that is responsible for writing data to the audit trail, attempts to write complete audit records. When file system space runs out, the system call terminates without releasing the current audit record. When the system call resumes, it can then repeat the truncated record. For more information, see the auditsvc(2) man page.

Device Allocation Reference

Device allocation protects removable media from unauthorized use. By requiring that a user allocate a device, or by denying a user permission to use a device, you can protect your site from loss of data, computer viruses, and other security breaches. The following section provides information about BSM device allocation.

Components of the Device-Allocation Mechanism

The components of the device-allocation mechanism are as follows:

• The allocate, deallocate, dminfo, and list_devices commands. For more information, see "Using the Device-Allocation Commands".

• The /etc/security/device_allocate file. See the device_allocate(4) man page.

• The /etc/security/device_maps file. See the device_maps(4) man page.

• A lock file in the /etc/security/dev directory for each allocatable device.

• The changed attributes of the device-special files that are associated with each allocatable device.

• Device-clean scripts for each allocatable device.

The device_allocate file, the device_map file, and the lock files are local configuration files. These files are not administered as name service databases because tape drives, diskette drives, and printers are all connected to specific machines.