Auditing Overview
Auditing is included in the full release and is part of the release media of the Trusted Solaris operating environment. By default, auditing is enabled. It can be disabled by modifying two files. All of the auditing software is included in the initial system installation in the following packages:
Auditing in Trusted Solaris is enabled by default, configurable by the system and security administrators, and extensible. By default, audit records are stored in workstation_name:/var/audit/. Events in the audit classes login_logout and non-attribute are audited for the root user.
The system administrator can provide dedicated partitions for audit records. The audit analyst can collect all records from all workstations in a Trusted Solaris network into one audit trail. The auditing records from a network of workstations can be viewed as one large file. Record selection using a variety of criteria is possible.
After audit data is collected into one audit trail, selection (called post-selection) and interpretation tools enable the audit reviewer to examine specific parts of the audit trail. For example, records can be selected for individual users or groups, for a host name, for a certain type of event on a specific day, or for a time of day.
To simplify audit administration, Trusted Solaris auditing provides classes of auditable events. When the security administrator specifies a class of events to be audited, all events in that class are audited. User commands or kernel system calls are auditable events. Classes of events to be audited can be specified per workstation. Specific users or roles (like root, for example) can be audited specially.
The security administrator can modify and extend the provided event - class mappings. For some events, event details that are not required by site security policy can be omitted from the audit record. Audit classes can be audited for failure, for success, or for both per workstation. Selecting which activities to monitor is called pre-selection. When the auditing subsystem encounters error conditions, the security administrator can specify whom to email with the information.
In the Trusted Solaris auditing subsystem, audit records are protected from snooping by the sensitivity label admin_high. Audit configuration files are accessible by the appropriate administrative role only, and sending records to the audit queue requires privilege. A special privilege, proc_audit_appl, is provided for ISVs and integrators to add their applications' audit records to the audit queue. Audit event numbers from 32768 to 65535 are available for third-party trusted applications.
Successful auditing depends on two other security features: identification and authentication. At login, after a user supplies a user name and password, a unique audit ID is associated with the user's process. The audit ID is inherited by every process started during the login session. Even when users change identity, for example, by assuming an administrative role, all of their actions are tracked with the same audit ID.
The rest of this chapter describes the auditing subsystem. Chapter 2, Auditing Setup describes how to set up and administer auditing. The latter part of the chapter contains setup and maintenance procedures. Chapter 3, Audit Trail Management and Analysis, describes the audit trail, how to manage its files, and how to read them. The latter part of the chapter contains typical procedures for managing and analyzing the audit trail.
- © 2010, Oracle Corporation and/or its affiliates