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
Figure 25-26 subject Token Format
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:
Figure 25-27 text Token Format
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
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 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.