JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
System Administration Guide: Security Services     Oracle Solaris 11 Express 11/10
search filter icon
search icon

Document Information


Part I Security Overview

1.  Security Services (Overview)

Part II System, File, and Device Security

2.  Managing Machine Security (Overview)

3.  Controlling Access to Systems (Tasks)

4.  Virus Scanning Service (Tasks)

5.  Controlling Access to Devices (Tasks)

6.  Using the Basic Audit Reporting Tool (Tasks)

7.  Controlling Access to Files (Tasks)

Part III Roles, Rights Profiles, and Privileges

8.  Using Roles and Privileges (Overview)

9.  Using Role-Based Access Control (Tasks)

10.  Role-Based Access Control (Reference)

11.  Privileges (Tasks)

12.  Privileges (Reference)

Part IV Oracle Solaris Cryptographic Services

13.  Oracle Solaris Cryptographic Framework (Overview)

14.  Oracle Solaris Cryptographic Framework (Tasks)

15.  Oracle Solaris Key Management Framework

Part V Authentication Services and Secure Communication

16.  Using Authentication Services (Tasks)

17.  Using PAM

18.  Using SASL

19.  Using Solaris Secure Shell (Tasks)

20.  Solaris Secure Shell (Reference)

Part VI Kerberos Service

21.  Introduction to the Kerberos Service

22.  Planning for the Kerberos Service

23.  Configuring the Kerberos Service (Tasks)

24.  Kerberos Error Messages and Troubleshooting

25.  Administering Kerberos Principals and Policies (Tasks)

26.  Using Kerberos Applications (Tasks)

27.  The Kerberos Service (Reference)

Part VII Oracle Solaris Auditing

28.  Oracle Solaris Auditing (Overview)

What Is Auditing?

How Is Auditing Related to Security?

How Does Auditing Work?

How is Auditing Configured?

Audit Terminology and Concepts

Audit Events

Audit Classes and Preselection

Audit Records and Audit Tokens

Audit Plugin Modules

Audit Logs

Storing and Managing the Audit Trail

Managing a Remote Repository

Auditing on a System With Zones

Oracle Solaris Auditing Enhancements in the Oracle Solaris 11 Express Release

29.  Planning for Oracle Solaris Auditing

30.  Managing Oracle Solaris Auditing (Tasks)

31.  Oracle Solaris Auditing (Reference)



Audit Terminology and Concepts

The following terms are used to describe the Oracle Solaris 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_class(4) and audit_event(4) man pages.

Audit directory

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 audited. 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 (the audit trail). The audit_remote plugin sends binary audit records to a remote repository. The audit_syslog plugin filters selected audit records to 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. These options include whether to record certain kinds of audit data. The options also include whether to suspend auditable actions when the audit queue is full.

For more information, see Determining 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 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 systems that run the audit service by using the default plugin, audit_binfile.

For more information, see Audit Trail.


Post-selection is 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 is 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 auditconfig(1M) man page.

Public object

A public object is 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.

Audit Events

Audit events represent auditable actions on a system. Audit events are listed in the /etc/security/audit_event file. Each audit event is connected to a system call or user command, and is assigned to one or more audit classes. For a description of the format of the audit_event file, see the audit_event(4) man page.

For example, the AUE_EXECVE audit event audits the execve() system call. The auditconfig -lsevent | grep AUE_EXECVE command displays this entry.

AUE_EXECVE                        23 ex,ps execve(2)

When you preselect either the audit class ex or the audit class ps, then every execve() system call is recorded in the audit queue.

Oracle Solaris auditing handles attributable and non-attributable events. Audit policy divides events into synchronous and asynchronous events, as follows:

In addition to the audit events that are defined by the Oracle Solaris audit service, third-party applications can generate audit events. Audit event numbers from 32768 to 65535 are available for third-party applications. Vendors need to contact Oracle Solaris representatives to reserve event numbers and get access to the audit interfaces.

Audit Classes and Preselection

Each audit event belongs 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, all the events in that class are recorded in the audit queue. For example, when you preselect the ps and na audit classes, execve() system calls and system boot actions, among other events, are recorded.

You can preselect for events on a system and for events initiated by a particular user. After the audit service is enabled, you can change the preselections.

Audit classes are defined in the /etc/security/audit_class file. Each entry contains the audit mask for the class, the name for the class, and a descriptive name for the class. For example, the ps and na class definitions appear in the audit_class file as follows:

0x00100000:ps:process start/stop

The audit classes include the two global classes: all and no. The audit classes are described in the audit_class(4) man page. For an alphabetical list of the classes, see Definitions of Audit Classes.

The mapping of audit events to classes is configurable. You can remove events from a class, add events to a class, and create a new class to contain selected events. For the procedure, see How to Change an Audit Event's Class Membership. To view the events that are mapped to a class, use the auditrecord -c class command.

Audit Records and Audit Tokens

Each audit record records 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. The following example shows a login audit record:

header,69,2,login - local,,example_system,2010-10-10 10:10:10.020 -07:00
subject,root,root,other,root,other,378,378,1234567891 2 example_system

The type of information that is saved for each audit event is defined by 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. In the preceding example, each line begins with the name of the audit token. The content of the audit token follows the name of the token. Together, the header, subject, and return audit tokens comprise the login - local audit record. To display the tokens that comprise an audit record, use the auditrecord -e event command.

For a detailed description of the structure of each audit token with an example of praudit output, see Audit Token Formats. For a description of the binary stream of audit tokens, see the audit.log(4) man page.

Audit Plugin Modules

You can specify which audit plugin modules are to handle the records that your preselection has placed in the audit queue. At least one plugin must be active. By default, the audit_binfile plugin is active. You configure plugins with the auditconfig -setplugin plugin-name command.

The Oracle Solaris audit services provides the following plugins:

To configure a plugin, see the auditconfig(1M) man page. For examples of plugin configuration, see the tasks in Configuring Audit Logs.

For information about the plugins, see the audit_binfile(5), audit_remote(5), and audit_syslog(5) man pages.

Audit Logs

Audit records are collected in audit logs. Oracle Solaris auditing provides three output modes for audit records.

A site can handle audit records in all formats. You can configure the systems at your site to use binary mode locally, to send binary files to a remote repository, or to use syslog mode, or to use any combination of these modes. The following table compares binary audit records with syslog audit records.

Table 28-1 Comparison of Binary Audit Records With syslog Audit Records

Binary and Remote Records
syslog Records
Binary – Writes to the file system

Remote – Streams to a remote repository

Uses UDP for remote logging
Data type
Record length
No limit
Up to 1024 characters per audit record
Binary – Stored on local disk, and in directories that are mounted by using NFS

Remote – Remote repository

Stored in a location that is specified in the syslog.conf file
How to configure
Binary – Set the p_dir attribute on the audit_binfile plugin

Remote – Set the p_hosts attribute on the audit_remote plugin and make the plugin active

Make the audit_syslog plugin active and edit the syslog.conf file
How to read
Binary – Typically, in batch mode, browser output in XML

Remote – Repository dictates the procedure

In real time, or searched by scripts that you have created for syslog

Plain text output

Guaranteed to be complete, and to appear in the correct order
Are not guaranteed to be complete
Coordinated Universal Time (UTC)
Time on the system that is being audited

Binary records provide the greatest security and coverage. Binary output meets the requirements of security certifications, such as the Common Criteria Controlled Access Protection Profile (CAPP).

The audit_binfile plugin writes the records to a file system that you protect from snooping. On a single system, all binary records are collected and are displayed in order. The UTC timestamp on binary logs enables accurate comparison when systems on one audit trail are distributed across time zones. The praudit -x command enables you to view the records in a browser in XML. You can also use scripts to parse the XML output.

The audit_remote plugin writes the records to a remote repository. The repository handles storage and post-selection.

In contrast, the syslog records provide greater convenience and flexibility. For example, you can collect the syslog data from a variety of sources. Also, when you monitor audit.notice events in the syslog.conf file, the syslog utility logs an audit record summary with the current timestamp. You can use the same management and analysis tools that you have developed for syslog messages from a variety of sources, including workstations, servers, firewalls, and routers. The records can be viewed in real time, and can be stored on a remote system.

By using syslog.conf to store audit records remotely, you protect log data from alteration or deletion by an attacker. On the other hand, when audit records are stored remotely, the records are susceptible to network attacks such as denial of service and spoofed source addresses. Also, UDP can drop packets or can deliver packets out of order. The limit on syslog entries is 1024 characters, so some audit records could be truncated in the log. On a single system, not all audit records are collected. The records might not display in order. Because each audit record is stamped with the local system's date and time, you can not rely on the timestamp to construct an audit trail for several systems.

For more information on audit logs, refer to the following:

Storing and Managing the Audit Trail

When the audit_binfile plugin is active, an audit directory holds audit files in binary format. A typical installation uses many audit directories. The contents of all audit directories comprise the audit trail. Audit records are stored in audit directories in the following order:

The directories are specified as arguments to the p_dir attribute of the audit_binfile plugin. A directory is not used until a directory that is earlier in the list is full. For an example with a list of directory entries, see How to Create ZFS File Systems for Audit Files.

Placing the audit files in the default audit root directory assists the audit reviewer when reviewing the audit trail. The auditreduce command uses the audit root directory to find all files in the audit trail. The default audit root directory is /var/audit. Audit files in the /var/audit directory are easily found by the auditreduce command. For more information, see auditreduce Command.

The audit service provides commands to combine and reduce files from the audit trail. The auditreduce command can merge audit files from the audit trail. The command can also filter files to locate particular events. The praudit command reads the binary files. Options to the praudit command provide output that is suitable for scripting and for browser display.

Managing a Remote Repository

When the audit_remote plugin is active, the remote repository handles management of the audit records.