Skip Navigation Links | |
Exit Print View | |
System Administration Guide: Security Services Oracle Solaris 10 1/13 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. 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)
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)
19. Using Secure Shell (Tasks)
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)
29. Planning for Oracle Solaris Auditing
Planning Oracle Solaris Auditing (Task Map)
Planning Oracle Solaris Auditing (Tasks)
How to Plan Storage for Audit Records
How to Plan Who and What to Audit
Cost of Increased Processing Time of Audit Data
Cost of Analysis of Audit Data
30. Managing Oracle Solaris Auditing (Tasks)
Audit policy determines the characteristics of the audit records for the local system. The policy options are set by a startup script. The bsmconv script, which enables the auditing service, creates the /etc/security/audit_startup script. The audit_startup script executes the auditconfig command to establish audit policy. For details about the script, see the audit_startup(1M) man page.
Most audit policy options are disabled by default to minimize storage requirements and system processing demands. You can dynamically enable and disable audit policy options with the auditconfig command. You can permanently enable and disable the policy options with the audit_startup script.
Use the following table to determine if the needs of your site justify the additional overhead that results from enabling one or more audit policy options.
Table 29-1 Effects of Audit Policy Options
Together, the ahlt policy and the cnt policy govern what happens when the audit queue is full and cannot accept more events. The 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 auditstatdrop field shows the number of audit records that are dropped in a zone.
The +ahlt -cnt policy states that processing halts when an 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.