Skip Navigation Links | |
Exit Print View | |
Oracle Solaris 11.1 Administration: Security Services Oracle Solaris 11.1 Information Library |
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. Verifying File Integrity by Using BART (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. Security Attributes in Oracle Solaris (Reference)
Part IV Cryptographic Services
11. Cryptographic Framework (Overview)
12. Cryptographic Framework (Tasks)
Part V Authentication Services and Secure Communication
14. Using Pluggable Authentication Modules
17. Using Simple Authentication and Security Layer
18. Network Services Authentication (Tasks)
19. Introduction to the Kerberos Service
20. Planning for the Kerberos Service
21. Configuring the Kerberos Service (Tasks)
22. Kerberos Error Messages and Troubleshooting
23. Administering Kerberos Principals and Policies (Tasks)
24. Using Kerberos Applications (Tasks)
25. The Kerberos Service (Reference)
Part VII Auditing in Oracle Solaris
Rights Profiles for Administering Auditing
Auditing and Oracle Solaris Zones
Audit Configuration Files and Packaging
Audit policy determines if 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 Auditing (Overview), 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.
Note - The cnt or ahlt policy is not triggered if the queue for at least one plugin can accept audit records.
The cnt and ahlt policies are independent and related. The combinations of the policies have the following effects:
-ahlt +cnt is the default policy that is shipped. This default lets an audited event be processed 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. In the global zone, the as_dropped counter records the count.
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 zone's as_dropped counter records the count.
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 in sites where a record of every audit event takes precedence over system availability. Programs will appear to hang until audit space becomes available. 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 in 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.