Managing Auditing in Oracle® Solaris 11.2

Exit Print View

Updated: July 2014
 
 

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

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.


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.2.

  1. (Optional) Save a backup copy of the audit_event file.
    # cp /etc/security/audit_event /etc/security/audit_event.orig
  2. 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.

Example 3-16  Mapping Existing Audit Events to a New Class

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)