Audit policy determines whether additional information is added to the audit trail.
The following policies add tokens to audit records: arge, argv, group, path, seq, trail, windata_down, windata_up, and zonename. The windata_down and windata_up policies are used by the Trusted Extensions feature of Oracle Solaris. For more information, see Chapter 22, Trusted Extensions and Auditing in Trusted Extensions Configuration and Administration.
The remaining policies do not add tokens. The public policy limits auditing of public files. The perzone policy establishes separate audit queues for non-global zones. The ahlt and cnt policies determine what happens when audit records cannot be delivered. For details, see Audit Policies for Asynchronous and Synchronous Events.
The effects of the different audit policy options are described in Understanding Audit Policy. For a description of audit policy options, see the –setpolicy option in the auditconfig(1M) man page. For a list of available policy options, run the command auditconfig -lspolicy. For the current policy, run the command auditconfig -getpolicy.
Together, the ahlt policy and the cnt policy govern what happens when the audit queue is full and cannot accept more events.
The –cnt and –ahlt policies are independent and related. The combination of the policies has the following effects:
-ahlt +cnt is the default policy that is shipped. This default allows the processing of an audited event even if the event cannot be logged.
The -ahlt policy states that if an audit record of an asynchronous event cannot be placed in the kernel audit queue, the system will count the events and continue processing.
The +cnt policy states that if a synchronous event arrives and the event cannot be placed in the kernel audit queue, the system will count the event and continue processing.
The -ahlt +cnt configuration is generally used at sites where processing must continue, even if continued processing could result in a loss of audit records. The auditstat drop field shows the number of audit records that are dropped in a zone.
The +ahlt -cnt policy states that processing halts when an asynchronous event cannot be added to the kernel audit queue.
The +ahlt policy states that if an audit record of an asynchronous event cannot be placed in the kernel audit queue, all processing is stopped. The system will panic. The asynchronous event will not be in the audit queue and must be recovered from pointers on the call stack.
The -cnt policy states that if a synchronous event cannot be placed in the kernel audit queue, the thread that is attempting to deliver the event will be blocked. The thread is placed in a sleep queue until audit space becomes available. No count is kept. Programs might appear to hang until audit space becomes available.
The +ahlt -cnt configuration is generally used at sites where a record of every audit event takes precedence over system availability. The auditstat wblk field shows the number of times that threads were blocked.
However, if an asynchronous event occurs, the system will panic, leading to an outage. The kernel queue of audit events can be manually recovered from a saved crash dump. The asynchronous event will not be in the audit queue and must be recovered from pointers on the call stack.
The -ahlt -cnt policy states that if an asynchronous event cannot be placed in the kernel audit queue, the event will be counted and processing will continue. When a synchronous event cannot be placed in the kernel audit queue, the thread that is attempting to deliver the event will be blocked. The thread is placed in a sleep queue until audit space becomes available. No count is kept. Programs might appear to hang until audit space becomes available.
The -ahlt -cnt configuration is generally used at sites where the recording of all synchronous audit events takes precedence over some potential loss of asynchronous audit records. The auditstat wblk field shows the number of times that threads were blocked.
The +ahlt +cnt policy states that if an asynchronous event cannot be placed in the kernel audit queue, the system will panic. If a synchronous event cannot be placed in the kernel audit queue, the system will count the event and continue processing.