This section covers various auditing error messages, preferences, and the auditing that is provided by other tools to help you debug audit problems.
Typically, different notices are sent to alert you of errors in the audit service. Review your email and the log files if you think that problems exist with the audit service.
Read the email sent to the audit_warn alias.
The audit_warn script sends alert messages to the audit_warn email alias. In the absence of a correctly configured alias, the messages are sent to the root account.
Review the log files for the audit service.
The output from the svcs -x auditd command lists the full path to the audit service log files.
Review the system log files.
The audit_warn script writes daemon.alert messages to the /var/log/syslog file.
The /var/adm/messages file might contain information.
After you locate and fix the problems, enable or restart the audit service.
# audit -s
The following sections describe possible problem cases and the steps to resolve them.
Auditing is enabled by default. If you believe that auditing has not been disabled, but no audit records are being sent to the active plugin, the causes might be one or a combination of the following factors discussed in this section. Note that to modify a system file, you must be assigned the solaris.admin.edit/path-to-system-file authorization. By default, the root role has this authorization.
To check whether auditing is running, use any of the following methods:
Verify the current audit condition.
The following output indicates that auditing is not running:
# auditconfig -getcond audit condition = noaudit
The following output indicates that auditing is running:
# auditconfig -getcond audit condition = auditing
Verify that the audit service is running.
The following output indicates that auditing is not running:
# svcs -x auditd svc:/system/auditd:default (Solaris audit daemon) State: disabled since Sun Oct 10 10:10:10 2010 Reason: Disabled by an administrator. See: http://support.oracle.com/msg/SMF-8000-05 See: auditd(1M) See: audit(1M) See: auditconfig(1M) See: audit_flags(5) See: audit_binfile(5) See: audit_syslog(5) See: audit_remote(5) See: /var/svc/log/system-auditd:default.log Impact: This service is not running.
The following output indicates that the audit service is running:
# svcs auditd STATE STIME FMRI online 10:10:10 svc:/system/auditd:default
If the audit service is not running, enable it. For the procedure, see Enabling and Disabling the Audit Service.
Use the following command to check if any plugins are active. At least one plugin must be active for the audit service to work.
# audit -v audit: no active plugin found
If no plugin is active, make one active.
# auditconfig -setplugin audit_binfile active # audit -v configuration ok
You might be attempting to use an audit class that has not been defined. For a description of creating the pf class, see How to Add an Audit Class.
For example, the following list of flags contains the pf class, which Oracle Solaris software did not deliver:
# auditconfig -getflags active user default audit flags = pf,lo(0x0100000000000000,00x0100000000001000) configured user default audit flags = pf,lo(0x0100000000000000,00x0100000000001000)
If you do not want to define the class, run the auditconfig -setflags command with valid values to reset the current flags. Otherwise, ensure the following when defining a class:
The audit class is defined in the audit_class file.
# grep pf /etc/security/audit_class
Verify class exists
0x0100000000000000:pf:profile
The mask is unique. If it is not unique, replace the mask.
# grep 0x0100000000000000 /etc/security/audit_class
Ensure mask is unique
0x0100000000000000:pf:profile
The customized class that you are using, although defined, might not have any events assigned to the class.
To verify whether events are assigned to the customized class, use one of the following methods:
# auditconfig -lsevent | egrep " pf|,pf|pf," AUE_PFEXEC 116 pf execve(2) with pfexec enabled
# auditrecord -c pf
List of audit events assigned to pf class
If events are not assigned to the class, assign the appropriate events to this class.
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 path,/usr/bin/ls attribute,100555,root,bin,21,320271,18446744073709551615 subject,jdoe,root,root,root,root,2404,50036632,82 0 mach1 return,success,0
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 path,/usr/bin/ls attribute,100555,root,bin,21,320271,18446744073709551615 exec_args,2,ls,/etc/security exec_env,49,MANPATH=/usr/share/man,USER=jdoe,GDM_KEYBOARD_LAYOUT=us,EDITOR=gedit, LANG=en_US.UTF-8,GDM_LANG=en_US.UTF-8,PS1=#,GDMSESSION=gnome,SESSIONTYPE=1,SHLVL=2, HOME=/home/jdoe,LOGNAME=jdoe,G_FILENAME_ENCODING=@locale,UTF-8, PRINTER=example-dbl, ... path,/lib/ld.so.1 attribute,100755,root,bin,21,393073,18446744073709551615 subject,jdoe,root,root,root,root,2424,50036632,82 0 mach1 group,root,other,bin,sys,adm,uucp,mail,tty,lp,nuucp,daemon return,success,0 zone,global sequence,197 trailer,1578
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 29, Specifying Audit Classes for syslog Output 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.
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.
As an administrator who is assigned the Audit Review rights profile, you can limit the size of binary files to facilitate archiving and searching. You can also create smaller binary files from the original file by using one of the options described in this section.
Use the p_fsize attribute to limit the size of individual binary audit files.
For a description of the p_fsize attribute, see the OBJECT ATTRIBUTES section of the audit_binfile(5) man page.
For an example, see Example 21, Limiting File Size for the audit_binfile Plugin.
Use the auditreduce command to select records and write those records to a smaller file for further analysis.
The auditreduce -lowercase options find specific records.
The auditreduce -Uppercase options write your selections to a file. For more information, see the auditreduce(1M) man page. See also Displaying Audit Trail Data.
The Oracle Solaris OS can audit all logins independent of source. If logins are not being audited, then the lo class for both attributable and non-attributable events is probably not set, This class audits logins, logouts, and screen locks. These classes are audited by default.
In this example, the output of the first two commands shows that the lo class for attributable and non-attributable events is not set. Then, the last two commands set the lo class to enable auditing of login events.
# auditconfig -getflags active user default audit flags = as,st(0x20800,0x20800) configured user default audit flags = as,st(0x20800,0x20800) # auditconfig -getnaflags active non-attributable audit flags = na(0x400,0x400) configured non-attributable audit flags = na(0x400,0x400) # auditconfig -setflags lo,as,st user default audit flags = as,lo,st(0x21800,0x21800) # auditconfig -setnaflags lo,na non-attributable audit flags = lo,na(0x1400,0x1400)
The following error indicates that you are not permitted to edit another user's crontab file:
not-sys# crontab -e sys crontab: The audit context for your shell has not been set.
Even if audit logs are not being collected and the crontab process is not being audited, crontab only permits the crontab file owner, sys in the preceding command, to edit the file.
To verify that you are permitted to edit another user's crontab file, check the output of the following command, where PID is the process ID of your login shell. If this shell does not report a valid audit context, then crontab denies edits to the file.
auditconfig -getpinfo PID
To edit a crontab file that you do not own requires the solaris.jobs.admin authorization.