JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
System Administration Guide: Security Services     Oracle Solaris 10 1/13 Information Library
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.  Controlling Access to Devices (Tasks)

5.  Using the Basic Audit Reporting Tool (Tasks)

6.  Controlling Access to Files (Tasks)

7.  Using the Automated Security Enhancement Tool (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 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 Secure Shell (Tasks)

20.  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 Auditing in Oracle Solaris

28.  Oracle Solaris Auditing (Overview)

What Is Auditing?

How Does Auditing Work?

How Is Auditing Related to Security?

Audit Terminology and Concepts

Audit Events

Audit Classes and Preselection

Audit Records and Audit Tokens

Audit Plugin Modules

Audit Logs

Storing the Audit Trail

Examining the Audit Trail

Auditing on a System With Oracle Solaris Zones

Auditing Enhancements in the Solaris 10 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 audit service. Some definitions include pointers to more complete descriptions.

Table 28-1 Oracle Solaris Auditing Terms

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.
Audit directory
A repository of audit files in binary format. For a description of the types of audit directories, see Audit Logs.
Audit event
A security-related system action that is audited. For ease of selection, events are grouped into audit classes. For a discussion of the system actions that can be audited, see Audit Events.
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 trail is full. For more information, see Determining Audit Policy.
Audit record
Audit data that is stored in audit files. 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 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 descriptions of all the audit tokens, see Audit Token Formats.
Audit trail
A collection of one or more audit files that store the audit data from all systems that run the audit service. For more information, see Audit Trail.
Preselection is the choice of which audit classes to monitor before you enable the audit service. The audit events of preselected audit classes appear in the audit trail. Audit classes that are not preselected are not audited, so their events do not appear in the audit trail. A postselection tool, the auditreduce command, selects records from the audit trail. For more information, see Audit Classes and Preselection.
Public objects
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 plugins
Modules that transfer the audit records in the kernel queue to a specified location. The plugin creates binary audit files (the audit trail). The plugin filters selected audit records to the syslog logs. For more information, see Audit Plugin Modules.

Audit Events

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 audit event is defined in the file by an event number, a symbolic name, a short description, and the set of audit classes to which the event belongs. For more information on the audit_event file, see the audit_event(4) man page.

For example, the following entry defines the audit event for the exec() system call:


When you preselect for auditing either the audit class ps or the audit class ex, then exec() system calls are recorded in the audit trail.

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

When the class to which an audit event belongs is preselected for auditing, the event is recorded in the audit trail. For example, when you preselect the ps and na audit classes for auditing, the exec() system calls and system boot actions, among other events, are recorded in the audit trail.

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.

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, you specify that all the events in that class should be recorded in the audit trail. You can preselect for events on a system and for events initiated by a particular user. After the audit service is running, you can dynamically add or remove audit classes from the preselected classes.

A postselection command, auditreduce, enables you to select records from the preselected audit records. For more information, see Examining the Audit Trail and the auditreduce(1M) man page.

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

There are 32 possible audit classes. The classes include the two global classes: all and no. The audit classes are described in the audit_class(4) man page.

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.

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,81,2,login - local,,2003-10-13 11:23:31.050 -07:00
subject,root,root,other,root,other,378,378,0 0 example_system
text,successful login

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. Together, the four audit tokens comprise the login audit record.

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 audit plugin modules to handle the records that your preselection has placed in the audit queue. The plugins are entries in the audit_control file.

For the syntax of the audit_control file, see the audit_control(4) man page. For examples, see the tasks in Configuring Audit Files (Task Map).

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

Audit Logs

Audit records are collected in audit logs. Oracle Solaris auditing provides two output modes for audit logs. Logs that are called audit files store audit records in binary format. The set of audit files from a system or site provide a complete audit record. The complete audit record is called the audit trail.

The syslog utility collects and stores text version summaries of the audit record. A syslog record is not complete. The following example shows a syslog entry for a login audit record:

Oct 13  11:24:11 example_system auditd: [ID 6472 audit.notice] \
        login - login ok session 378 by root as root:other

A site can store audit records in both formats. You can configure the systems at your site to use binary mode, to use syslog mode, or to use both modes. The following table compares binary audit records with syslog audit records.

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

Binary Records
syslog Records
Writes to the file system
Uses UDP for remote logging
Data type
Record length
No limit
Up to 1024 characters per audit record
Stored on local disk, and in directories that are mounted by using NFS
Stored in a location that is specified in the syslog.conf file
How to configure
Edit audit_control file, and protect and NFS-mount audit directories
Edit audit_control file, and edit syslog.conf file
How to read
Typically, in batch mode

Browser output in XML

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
Greenwich Mean Time (GMT)
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 records are written to a file system that you protect from snooping. On a single system, all binary records are collected and are displayed in order. The GMT 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.

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 the Audit Trail

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 in the audit_control file. A directory is not used until a directory that is earlier in the list is full. For an annotated audit_control file with a list of directory entries, see Example 30-3.

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 /etc/security/audit. This directory is symbolically linked to /var/audit. Audit files in directories that are named /var/audit/hostname/files are easily found by the auditreduce command. For more information, see auditreduce Command.

Examining the Audit Trail

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.