Skip Navigation Links | |
Exit Print View | |
Oracle Solaris Administration: Security Services Oracle Solaris 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. Virus Scanning Service (Tasks)
5. Controlling Access to Devices (Tasks)
6. Using the Basic Audit Reporting Tool (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. Network Services Authentication (Tasks)
17. Using Secure Shell (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
Audit Terminology and Concepts
Audit Classes and Preselection
Audit Records and Audit Tokens
Storing and Managing the Audit Trail
How Is Auditing Related to Security?
Auditing on a System With Oracle Solaris Zones
Auditing generates audit records when specified events occur. Most commonly, events that generate audit records include the following:
System startup and system shutdown
Login and logout
Process creation or process destruction, or thread creation or thread destruction
Opening, closing, creating, destroying, or renaming of objects
Use of privilege capabilities or role-based access control (RBAC)
Identification actions and authentication actions
Permission changes by a process or user
Administrative actions, such as installing a package
Site-specific applications
Audit records are generated from three sources:
By an application
As a result of an asynchronous audit event
As a result of a process system call
After the relevant event information has been captured, the information is formatted into an audit record. Contained in each audit record is information that identifies the event, what caused the event, the time of the event, and other relevant information. This record is then placed in an audit queue for the active plugins. At least one plugin must be active, although all plugins can be active.
By default, one plugin is active. This is the audit_binfile plugin, which writes the audit records to audit files. These files are stored locally in binary format. An active audit_remote plugin sends these records to a remote repository. An active audit_syslog plugin sends text summaries to the syslog utility. For an illustration, see Figure 26-1.
When stored locally, audit files can be in one or more ZFS pools. ZFS pools can make local storage easy to manage. These pools can be on different systems and on different but linked networks. The collection of audit files that are linked together is considered an audit trail.
For more information, see How Is Auditing Configured?, Audit Logs, and Audit Plugin Modules.