Managing Auditing in Oracle® Solaris 11.2

Exit Print View

Updated: July 2014
 
 

Audit Terminology and Concepts

The following terms are used to describe the audit service. Some definitions include pointers to more complete descriptions.

audit class

A grouping of audit events. Audit classes provide a way to select a group of events to be audited.

For more information, see Audit Classes and Preselection, and the audit_flags(5), audit_class(4), and audit_event(4) man pages.

audit file system

A repository of audit files in binary format.

For more information, see Audit Logs and the audit.log(4) man page.

audit event

A security-related system action that is auditable. For ease of selection, events are grouped into audit classes.

For more information, see Audit Events and the audit_event(4) man page.

audit flag

An audit class that is supplied as an argument to a command or keyword. A flag can be prefixed by a plus sign or minus sign to indicate that the class is audited for success (+) or failure (-). A preceding caret (^) indicates that a success is not to be audited (^+) or a failure is not to be audited (^-).

For more information, see the audit_flags(5) man page and Audit Class Syntax.

audit plugin

A module that transfers the audit records in the queue to a specified location. The audit_binfile plugin creates binary audit files. Binary files comprise the audit trail, which is stored on audit file systems. The audit_remote plugin sends binary audit records to a remote repository. The audit_syslog plugin summarizes selected audit records in the syslog logs.

For more information, see Audit Plugin Modules and the module man pages, audit_binfile(5), audit_remote(5), and audit_syslog(5).

audit policy

A set of auditing options that you can enable or disable at your site. You can specify whether to record certain kinds of audit data, and whether to suspend auditable actions when the audit queue is full.

For more information, see Understanding Audit Policy and the auditconfig(1M) man page.

audit record

Audit data that is collected in the audit queue. An audit record describes a single audit event. Each audit record is composed of audit tokens.

For more information, see Audit Records and Audit Tokens and the audit.log(4) man page.

audit token

A field of an audit record or event. Each audit token describes an attribute of an audit event, such as a user, a group, a program, or other object.

For more information, see Audit Token Formats and the audit.log(4) man page.

audit trail

A collection of one or more audit files that store the audit data from all audited systems that use the default plugin, audit_binfile.

For more information, see Audit Trail.

local auditing

The collecting of audit records that are generated on the local system. The records can be generated in the global zone or in non-global zones, or both.

For more information, see Audit Plugin Modules.

post-selection

The choice of which audit events to examine in the audit trail. The default active plugin, audit_binfile, creates the audit trail. A post-selection tool, the auditreduce command, selects records from the audit trail.

For more information, see the auditreduce(1M) and praudit(1M) man pages.

preselection

The choice of which audit classes to monitor. The audit events of preselected audit classes are collected in the audit queue. Audit classes that are not preselected are not audited, so their events do not appear in the queue.

For more information, see Audit Classes and Preselection and the audit_flags(5) and auditconfig(1M) man pages.

public object

A file that is owned by the root user and readable by the world. For example, files in the /etc directory and the /usr/bin directory are public objects. Public objects are not audited for read-only events. For example, even if the file_read (fr) audit class is preselected, the reading of public objects is not audited. You can override the default by changing the public audit policy option.

remote auditing

The audit remote server (ARS) that receives and stores audit records from a system that is being audited and is configured with an active audit_remote plugin. To distinguish an audited system from an ARS, the audited system can be referred to as the “locally audited system.”

For more information, see the –setremote options on the auditconfig(1M) man page and Audit Remote Server.