How Does Auditing Work?

Auditing generates audit records when specified events occur. Most commonly, events that generate audit records include the following:

• System startup and system shutdown

• Login and logout

• Process creation or process destruction, or thread creation or thread destruction

• Opening, closing, creating, destroying, or renaming of objects

• Use of privilege capabilities or role-based access control (RBAC)

• Identification actions and authentication actions

• Permission changes by a process or user

• Administrative actions, such as installing a package

• Site-specific applications

Audit records are generated from three sources:

• By an application

• As a result of an asynchronous audit event

• As a result of a process system call

Once the relevant event information has been captured, the information is formatted into an audit record. Contained in each audit record is information that identifies the event, what caused the event, the time of the event, and other relevant information. This record is then placed in an audit queue for the active plugins.

The default active plugin, audit_binfile, writes the records to audit files. These audit records are stored locally in binary format. An active audit_remote plugin sends these records to a remote repository. An active audit_syslog plugin sends text summaries to the syslog utility. For an illustration, see Figure 28-1.

Audit files in binary format can be stored locally or sent to a remote repository. When stored locally, the files can be in a local file system and on NFS-mounted file servers. ZFS pools can make local storage easy to manage. These pools can be on different systems and on different but linked networks. The collection of audit files that are linked together is considered an audit trail.

For a description of the plugins, see Audit Plugin Modules. For a comparison of the plugins, see Audit Logs.