Managing Auditing in Oracle® Solaris 11.2

Exit Print View

Updated: July 2014

Volume of Audit Records Is Large

After you have determined which events must be audited at your site, use the following suggestions to create audit files with just the information that you require. Note that to assign flags to users, roles, and rights profiles, you must assume the root role.

  • Specifically, avoid adding events and audit tokens to the audit trail. The following policies increase the size of the audit trail.


    Adds environment variables to execv audit events. Although auditing execv events can be costly, adding variables to the audit record is not.


    Adds command parameters to execv audit events. Adding command parameters to the audit record is not costly.


    Adds a group token to audit events that include an optional newgroups token.


    Adds a path token to audit events that include an optional path token.


    If file events are being audited, adds an event to the audit trail every time an auditable event happens to a public object. File classes include fa, fc, fd, fm, fr, fw, and cl. For the definition of a public file, see Audit Terminology and Concepts.


    Adds a sequence token to every audit event.


    Adds a trailer token to every audit event.


    On a system that is configured with Trusted Extensions, adds events when information in a labeled window is downgraded.


    On a system that is configured with Trusted Extensions, adds events when information in a labeled window is upgraded.


    Adds the zone name to every audit event. If the global zone is the only configured zone, adds the string zone, global to every audit event.

    The following audit record shows the use of the ls command. The ex class is being audited and the default policy is in use:

    header,129,2,AUE_EXECVE,,mach1,2010-10-14 11:39:22.480 -07:00
    subject,jdoe,root,root,root,root,2404,50036632,82 0 mach1

    The following is the same record when all policies are turned on:

    header,1578,2,AUE_EXECVE,,mach1,2010-10-14 11:45:46.658 -07:00
    HOME=/home/jdoe,LOGNAME=jdoe,G_FILENAME_ENCODING=@locale,UTF-8, PRINTER=example-dbl,
    subject,jdoe,root,root,root,root,2424,50036632,82 0 mach1
  • Use the audit_syslog plugin to send some audit events to syslog.

    Do not send those audit events to the audit_binfile or audit_remote plugin. This strategy works only if you are not required to keep binary records of the audit events that you send to the syslog logs.

  • Set fewer system-wide audit flags and audit individual users.

    Reduce the amount of auditing for all users by reducing the number of audit classes that are audited system-wide.

    Use the audit_flags keyword to the roleadd, rolemod, useradd, and usermod commands to audit events for specific users and roles. For examples, see Example 4–11 and the usermod(1M) man page.

    Use the always_audit and never_audit properties of the profiles command to audit events for specific rights profiles. For information, see the profiles(1) man page.

    Note -  Like other security attributes, audit flags are affected by search order. For more information, see Order of Search for Assigned Rights in Securing Users and Processes in Oracle Solaris 11.2 .
  • Create your own customized audit class.

    You can create audit classes at your site. Into these classes, put only those audit events that you need to monitor. For the procedure, see How to Add an Audit Class.

    Note -  For information about the effects of modifying an audit configuration file, see Audit Configuration Files and Packaging.