The following terms are used to describe the BSM service. Some definitions include pointers to more complete descriptions.
Table 20–1 BSM Terms
Term |
Definition |
---|---|
Audit class |
A grouping of audit events. Audit classes provide a way to manage a group of events. For more information, see Audit Classes. |
Audit directory |
A repository of audit files. For a description of the types of audit directories, see Audit Directory. |
Audit event |
A security-related system action that is audited. For a discussion of the types of audit events, see Audit Events. |
Audit flag |
A short name for a class. The audit flag is used to determine which classes of events to audit and when to audit those classes of events. For more information about audit flags, see Audit Flags. |
Audit policy |
A set of auditing options that you can enable or disable for a particular configuration.These options include whether to record certain kinds of audit data. The options also include whether to suspend auditable actions when the audit trail is full. |
Audit record |
Audit data. Audit data is stored in binary form. An audit record describes a single audit event. Each audit record is composed of audit tokens. For more information about audit records, see Audit Records and Audit Tokens. |
Audit token |
A set of audit data. Audit tokens are stored in binary form. Each audit token describes an attribute of an audit event, such as a process, a path, or other object. For descriptions of all the audit tokens, see Audit Token Formats. |
Audit trail |
A collection of one or more audit files that might reside in separate audit file partitions. |
Device allocation |
A mechanism that enables you to restrict use of a device, as well as to erase any leftover data after a device has been used. For a description of device allocation, see Device Allocation. |
Public objects |
A public object is a file that is in a system directory, such as the /etc or the /usr/bin directory. System directories are readable by everyone. The files in system directories are often read for information or for execution. In the Solaris 9 8/03 release, public objects, by default, are no longer audited for read-only events. For example, even if the fr audit flag is turned on, the reading of public objects is not audited. The public policy flag argument to the auditconfig -setpolicy command determines the policy setting. |
Security-relevant system actions can be audited. These auditable actions are defined as audit events. Audit events are listed in the /etc/security/audit_event file. Each auditable event is defined in the file by a symbolic name, an event number, a set of preselection classes, and a short description. See the audit_event(4) man page.
There are several categories of audit events. The primary distinction is between kernel-level events and user-level events. Events that are generated by the kernel are called kernel-level events. Events that are generated by applications are called user-level events. Kernel-level events have a lower audit event number than a user-level event, as shown in the following table.
Table 20–2 Audit Event Categories
Number Range |
Type of Event |
|
---|---|---|
1–2047 |
Kernel-level audit events |
|
2048–65535 |
User-level audit events |
|
|
2048–32767 |
Reserved for SunOS user-level programs |
|
32768–65535 |
Events that are generated by the kernel are system calls. System calls have audit event numbers between 1 and 2047. The event names for kernel events begin with AUE_, followed by an uppercase mnemonic for the event. For example, the event number for the creat() system call is 4, and the event name is AUE_CREAT.
Events that are generated by application software are outside the kernel. Application software generates user-level events. User-level events range in number from 2048 to 65535. The event names begin with AUE_, followed by a lowercase mnemonic for the event. For example, the event number for the rlogin command is 6155, and the event name is AUE_rlogin. Table 20–2 shows general categories of user-related events.
Most events are attributable to an individual user, but some events are not. Events are nonattributable if the events occur at the kernel-interrupt level, or if the events occur before a user is identified and authenticated. Nonattributable events are auditable. The following example lists two nonattributable events from the /etc/security/audit_event file:
153:AUE_ENTERPROM:enter prom:na 6156:AUE_mountd_mount:mount:na |
AUE_ENTERPROM is a kernel-level na event. AUE_mountd_mount is a user-level na event.
Each audit event is also defined as belonging to an audit class or classes. Audit classes are convenient containers for large numbers of audit events. When you preselect a class to be audited, you preselect for auditing all the events in that class. Audit classes are defined in the /etc/security/audit_class file. Each entry contains the name of the class, its audit mask, and its short name.
0x00000010:fc:file create 0x00000400:na:non-attribute |
The mapping of audit events to classes is configurable. These configuration changes are made in the audit_event file.
An auditable event is recorded in the audit trail when you preselect an audit class for auditing that includes the specific event. There are 32 possible audit classes. The classes include the two global classes: all and no. The audit classes are described in Table 23–1. See also the audit_class(4) man page.
Audit flags are the short names for audit classes. Audit flags are used in the audit_control file to specify machine-wide defaults for auditing on the machine. The audit_control file is described in The audit_control File.
You can make exceptions to the machine-wide auditing defaults for individual users. You put audit flags in a user's entry in the audit_user file. The audit flags are also used as arguments to the auditconfig command. See the auditconfig(1M) and audit_user(4) man pages.
Each audit record describes the occurrence of a single audited event. The record includes information such as who did the action, which files were affected, what action was attempted, and where and when the action occurred. For example, the following line shows an audit record when processed by the praudit command:
header,81,2,login - local,,Mon May 6 16:55:48 PDT 2002, + 486 msec subject,root,root,other,root,other,378,378,0 0 example_machine text,successful login return,success,0 |
Audit records are collected in an audit file. The set of audit files from a machine or site is called the audit trail. For a description of how audit files are handled, see the audit.log(4) man page. Audit records can be converted to a readable format by the praudit command. For examples of praudit output, see The praudit Command. See also the praudit(1M) man page.
The type of information that is saved for each audit event is defined in a set of audit tokens. Each time an audit record is created for an event, the record contains some or all of the tokens that are defined for the event. The nature of the event determines which tokens are recorded. You can generate audit record descriptions with the bsmrecord command. The following output shows the structure of the audit record that is generated when the creat() system call is used. The lines beginning with header are the audit tokens.
creat system call creat see creat(2) event ID 4 AUE_CREAT class fc (0x00000010) header path [attribute] subject return |
For more information, see How to Display Audit Record Formats. For a description of the structure of each audit token, see Audit Token Formats. The audit.log(4) man page also lists the audit tokens.
An audit directory holds a collection of audit files. A typical installation uses many audit directories. The three types of audit directories are as follows:
Primary audit directory – A directory where the audit files for a system are placed under normal conditions.
Secondary audit directory – A directory where the audit files for a system are placed if the primary directory is full or not available.
Directory of last resort – A local audit directory that is used if the primary audit directory and all secondary audit directories are not available.