The Audit Mechanism

Auditing is enabled by an audit daemon that uses six configurable audit files: audit_class(4), audit_event(4), audit_control(4), audit_user(4), audit_startup(1M), and audit_warn(1M). These files are in the /etc/security directory and determine what to audit, where to put the audit logs, and what to do when there is trouble. By default, events in the lo (login/logout) audit class are audited for the root role, the audit records are written to the /var/audit directory, and no one receives mail when there is trouble.

You can suspend and re-enable auditing without rebooting the system, and you can dynamically change what is being audited.

Audit Startup

Auditing is enabled when the audit daemon starts, usually when the system is booted (see the auditd(1M) man page). When troubleshooting, the daemon can be started manually by executing /usr/sbin/auditd in an admin_high shell in the secadmin role.

The existence of a file with the pathname /etc/security/audit_startup causes the audit daemon to be run automatically when the system enters multiuser mode. The file is actually an executable script that is invoked as part of the startup sequence just prior to the execution of the audit daemon (see the audit_startup(1M) man page). A default audit_startup script that automatically configures the event-to-class mappings and sets the audit policies is created during audit package installation.

The security administrator can edit the audit_startup script to alter the default audit policy. See Setting Audit Policies for more information on audit policy.

Audit Classes and Events

Security-relevant actions may be audited. The system actions that are auditable are defined as audit events 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).

Most events are attributable to an individual user. However, some events are nonattributable because they occur at the kernel-interrupt level or before a user is identified and authenticated. Nonattributable events are auditable as well.

Each audit event is also defined as belonging to an audit class or classes. Administrators name an audit class (called an audit flag) when specifying for the audit daemon what is to be audited. When naming a class, one simultaneously addresses all of the events in that class. The mapping of audit events to classes is configurable and the classes themselves are configurable. These configuration changes are made in the audit_event file. New classes are added to the audit_class file.

Whether an auditable event is recorded in the audit trail depends on whether the administrator preselects an audit class that includes the specific event.

Audit Classes

The file /etc/security/audit_class stores class definitions. Site-specific definitions can be added and default definitions can be changed. Each entry in the file has the form:

mask:name:description

Each class is represented as a bit in the mask, which is an unsigned integer, giving 32 different available classes plus two global classes, all and no. all is a conjunction of all allowed classes. no is the invalid class. Events mapped to the no class are not audited. Events mapped solely to the no class are not audited even if the all class is turned on. Below is a sample audit_class file:

0x00000000:no:invalid class
0x00000001:fr:file read
0x00000002:fw:file write
0x00000004:fa:file attribute access
0x00000008:fm:file attribute modify
0x00000010:fc:file create
0x00000020:fd:file delete
0x00000040:cl:file close
0x00000100:nt:network
0x00000200:ip:ipc
0x00000400:na:non-attribute
0x00001000:lo:login or logout
0x00002000:ax:x server
0x00004000:ap:application
0x000f0000:ad:administrative
0x00010000:ss:change system state
0x00020000:as:system-wide administration
0x00040000:aa:audit administration
0x00080000:ao:other administration
0x00300000:pc:process
0x00100000:ps:process start/stop
0x00200000:pm:process modify
0x20000000:io:ioctl
0x40000000:fn:fcntl
0x80000000:ot:other
0xffffffff:all:all classes

If the no class is actually turned on for auditing, the audit trail fills up with records for the audit event AUE_NULL.

Kernel Events

Events generated by the kernel (system calls) have 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.

Within kernel events there is one pseudo-event defined, AUE_UPRIV, which audits use-of-privilege decisions.

When the AUE_UPRIV pseudo-event is preselected, audit information is collected internally even if the underlying kernel event is not selected. For example, if the kernel event AUE_OPEN_R is not selected for auditing but the pseudo-event AUE_UPRIV is enabled, the kernel event AUE_OPEN_R will be written to the audit trail if a use-of-privilege decision was part of the AUE_OPEN_R system call.

User-Level Events

Events generated by trusted application software outside the kernel range from 2048 to 65535. The event names begin with AUE_, followed by a lowercase mnemonic for the event. The file /etc/security/audit_event lists individual events in numerical order. For a listing of events by class, see Appendix A, Event-to-Class Mappings. The following table shows general categories of user-related events.

Table 1–1 Audit Event Categories

Number Range	Type of Event
2048–65535	User-level audit events
2048–32767	Reserved for Solaris and Trusted Solaris user-level programs
32768–65536	Available for third-party applications

Non-Attribute Events

Events that are not attributable to a user, such as AUE_ENTERPROM.

Audit Records

Each audit record describes the occurrence of a single audited event and includes such information as who did the action, which files were affected, what action was attempted, and where and when it occurred.

The type of information saved for each audit event is defined as a set of audit tokens. The definition and structure of every audit token are described in detail in Audit Token Structure. Each time an audit record is created for an event, the record contains some or all of the tokens defined for it, depending on the nature of the event and the audit policy. The audit record descriptions in Audit Records list in order the audit tokens defined for each event.

Audit records are stored in audit files. An audit trail is one or more audit files in a distributed system. The construction of the audit trail is shown in Figure 1–1. The audit trail may be converted to a human readable format by the praudit(1M) command. Specific audit records can be selectively chosen using the auditreduce(1M) command. See Audit Files Management, for details.

Figure 1–1 From the Audit Token to the Audit Trail