Skip Navigation Links | |
Exit Print View | |
System Administration Guide: Security Services Oracle Solaris 10 8/11 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 Oracle Solaris Secure Shell (Tasks)
20. Oracle Solaris Secure Shell (Reference)
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 Oracle Solaris Auditing
28. Oracle Solaris Auditing (Overview)
29. Planning for Oracle Solaris Auditing
30. Managing Oracle Solaris Auditing (Tasks)
31. Oracle Solaris Auditing (Reference)
Files Used in the Audit Service
Rights Profiles for Administering Auditing
Auditing and Oracle Solaris Zones
Proscess Audit Characteristics
The audit trail is contains binary audit files. The trail is created by the auditd daemon. Once the audit service has been enabled with the bsmconv command, the auditd daemon starts when the system is booted. The auditd daemon is responsible for collecting the audit trail data and writing the audit records.
The audit records are stored in binary format on file systems that are dedicated to audit files. Even though you can physically locate audit directories within file systems that are not dedicated to auditing, do not do so except for directories of last resort. Directories of last resort are directories where audit files are written only when no other suitable directory is available.
There is one other scenario where locating audit directories outside of dedicated audit file systems could be acceptable. You might do so in a software development environment where auditing is optional. To make full use of disk space might be more important than to keep an audit trail. However, in a security-conscious environment, the placement of audit directories within other file systems is not acceptable.
You should also consider the following factors when administering audit file systems:
A host should have at least one local audit directory. The local directory can be used as a directory of last resort if the host is unable to communicate with the audit server.
Mount audit directories with the read-write (rw) option. When you mount audit directories remotely, also use the intr and noac options.
List the audit file systems on the audit server where they reside. The export list should include all systems that are being audited at the site.