How to Change an Audit Event's Class Membership
You might want to change an audit event's class membership to reduce the size of an existing audit class, or to place the event in a class of its own.
 | Caution - Never comment out events in the audit_event file. This file is used by the praudit command to read binary audit files. Archived audit files might contain events that are listed in the file. Also, never remove any existing audit classes. |
When you reconfigure audit event-class mappings on one system, copy the change to all systems that are being audited. Best practice is to change event-class mappings before the first users log in.
Note - For information about the effects of modifying an audit configuration file, see Audit Configuration Files and Packaging.
Tip - In Oracle Solaris you can create your own package that contains files and replace the Oracle Solaris packages with your site-customized files. When you set the preserve attribute to true in your package, the pkg subcommands, such as verify, fix, revert, and so on, will run relative to your packages. For more information, see the pkg(1) and pkg(5) man pages.
Before You Begin
You must become an administrator who is assigned the solaris.admin.edit/etc/security/audit_event authorization. By default, only the root role has this authorization. For more information, see Using Your Assigned Administrative Rights in Securing Users and Processes in Oracle Solaris 11.3.
- (Optional)
Save a backup copy of the audit_event file.
# cp /etc/security/audit_event /etc/security/audit_event.orig
-
Change the class to which particular events belong by changing the
class-list of the events.
Each entry has the following format:
number:name:description:class-list
- number
-
The audit event ID.
- name
-
The name of the audit event.
- description
-
Typically, the system call or executable that triggers the creation of an audit record.
- class-list
-
A comma-separated list of audit classes.
-
Refresh the kernel events.
# auditconfig -conf Configured 283 kernel events.
This example maps an existing audit event to the new class that was created in Example 15, Creating a New Audit Class. By default, the AUE_PFEXEC audit event is mapped to several audit classes. By creating the new class, the administrator can audit AUE_PFEXEC events without auditing the events in the other classes.
# grep pf /etc/security/audit_class 0x0100000000000000:pf:profile command # grep AUE_PFEXEC /etc/security/audit_event 116:AUE_PFEXEC:execve(2) with pfexec enabled:ps,ex,ua,as # pfedit /etc/security/audit_event #116:AUE_PFEXEC:execve(2) with pfexec enabled:ps,ex,ua,as 116:AUE_PFEXEC:execve(2) with pfexec enabled:pf # auditconfig -setflags lo,pf user default audit flags = pf,lo(0x0100000000001000,0x0100000000001000)