|Skip Navigation Links|
|Exit Print View|
|Trusted Extensions Configuration and Administration Oracle Solaris 11 Information Library|
Auditing in Trusted Extensions requires the same planning as in the Oracle Solaris OS. For details about planning, see Chapter 27, Planning for Auditing, in Oracle Solaris Administration: Security Services.
In Trusted Extensions, auditing is the responsibility of separate roles.
The root role assigns audit flags to users and rights profiles, and edits system files, such as the audit_warn script.
The System Administrator role sets up the disks and the network of audit storage. This role can also review the audit records.
The Security Administrator role decides what is to be audited and configures auditing. The initial setup team created this role by completingHow to Create the Security Administrator Role in Trusted Extensions.
Note - A system only records the events in audit classes that the security administrator has preselected. Therefore, any subsequent audit review can only consider the events that have been recorded. As a result of misconfiguration, attempts to breach the security of the system can go undetected, or the administrator is unable to detect the user who is responsible for an attempted breach of security. Administrators must regularly analyze audit trails to check for breaches of security.
The procedures to configure and manage auditing in Trusted Extensions differ only slightly from Oracle Solaris procedures. In Trusted Extensions, audit configuration is performed in the global zone. Because per-zone auditing is not configured, user actions are audited identically in the global zone and in labeled zones. The label of every audited event is included in the audit record.
The security administrator can select audit policies that are specific to Trusted Extensions, windata_down and windata_up.
When reviewing audit records, the system administrator can select audit records by label. For more information, see the auditreduce(1M) man page.