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.
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.
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.2.
# cp /etc/security/audit_event /etc/security/audit_event.orig
Each entry has the following format:
The audit event ID.
The name of the audit event.
Typically, the system call or executable that triggers the creation of an audit record.
A comma-separated list of audit classes.
This example maps an existing audit event to the new class that was created in Example 3–15. 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,cusa # pfedit /etc/security/audit_event #116:AUE_PFEXEC:execve(2) with pfexec enabled:ps,ex,ua,as,cusa 116:AUE_PFEXEC:execve(2) with pfexec enabled:pf # auditconfig -setflags lo,pf user default audit flags = pf,lo(0x0100000000001000,0x0100000000001000)