LKSF › Solaris Security › Auditing
One of the less known features in Solaris is Auditing. Auditing solves an important problem: What happens on my system, and whodunit? When something strange happens on your system or you recognize that you are not the only one who owns your system, it’s a good thing to have some logs for analysis.
The nice thing about auditing in Solaris: It’s quite simple to activate. In this article I will give you a short overview to enable and use auditing in Solaris. This feature is really old, it’s been in Solaris since the last century but nevertheless it’s a less known Solaris feature.
Some terms
There are some special terms in auditing. I want to give you a short definition of them as I have to use them in this article. I’ve copied these definitions from the manual for Solaris Auditing.
- Audit events: A security-related system action that is audited. For ease of selection, events are grouped into audit classes.
- Audit Class: A grouping of audit events. Audit classes provide a way to select a group of events to be audited.
- Audit policy: A set of auditing options that you can enable or disable at your site. These options include whether to record certain kinds of audit data. The options also include whether to suspend auditable actions when the audit trail is full.
Configuring basic auditing
You have to search for a place in your filesystem. It’s a good practice to use its own filesystem, as auditing will eat away your filesystem space until there is nothing left and this is a bad idea for the root file system. But in this example I will omit this step.
At first login as root. Okay, you need a place to store the audit logs. It’s important to change the rights of the directory to ensure only root can access it.
mkdir /var/audit/aragorn-sol
chmod -R 750 /var/audit/aragorn-sol
Then go to /etc/security and edit the file /etc/security/audit_control. This file controls what classes of information are logged and where you write the log. For example: The lo is the audit class for all events in regard to logins and logoffs:
dir:/var/audit/aragorn-sol
flags:lo
minfree:20
naflags:lo
Okay, configuration is done. But let’s have another look at the file /etc/security/audit_startup. The commands in this script control the audit policies and thus the behavior of the logging and the amount of information in the log records:
/usr/bin/echo "Starting BSM services."
/usr/sbin/auditconfig -setpolicy +cnt
/usr/sbin/auditconfig -conf
/usr/sbin/auditconfig -aconf
The second line is the most interesting. Without this line the system would stop user interaction when the system is unable to log. You would deactivate this behavior when logging is more important than system availability. For the moment we don’t change this file.
Start the auditing
Now activate auditing. You have to reboot after the activation:
# ./bsmconv
This script is used to enable the Basic Security Module (BSM).
Shall we continue with the conversion now? [y/n] y
bsmconv: INFO: checking startup file.
bsmconv: INFO: turning on audit module.
bsmconv: INFO: initializing device allocation.
The Basic Security Module is ready.
If there were any errors, please fix them now.
Configure BSM by editing files located in /etc/security.
Reboot this system now to come up with BSM enabled.
# reboot
Two short checks … auditd runs …
# svcs | grep "auditd"
online 23:30:03 svc:/system/auditd:default
… and the system starts to gather audit logs:
# ls -la
total 6
drwxr-x--- 2 root root 512 Feb 1 23:30 .
drwxr-xr-x 3 root sys 512 Feb 1 23:18 ..
-rw-r----- 1 root root 255 Feb 1 23:33 20080201223003.not_terminated.aragorn-sol
Okay, now you have completed the configuration. The system has started to write audit logs.
Managing the audit logs
Audit logs grow infinitely. To the maximum filesize in the used filesystem or the end of disk capacity … whichever occurs first. It’s a good practice to checkpoint the audit logs in a regular interval. It’s quite simple:
audit -n
With this command the current file gets closed and a new one gets opened.
# cd /var/audit/aragorn-sol/
# ls -l
total 24
-rw-r----- 1 root root 684 Feb 1 23:55 20080201223003.20080201225549.aragorn-sol
-rw-r----- 1 root root 571 Feb 2 00:06 20080201225549.20080201230639.aragorn-sol
-rw-r----- 1 root root 2279 Feb 2 00:10 20080201230834.20080201231010.aragorn-sol
-rw-r----- 1 root root 755 Feb 2 00:12 20080201231010.20080201231245.aragorn-sol
-rw-r----- 1 root root 4274 Feb 2 08:36 20080201231245.20080202073624.aragorn-sol
-rw-r----- 1 root root 200 Feb 2 08:36 20080202073624.not_terminated.aragorn-sol
Analyzing the audit trails
It doesn’t make sense to create audit logs without looking at them. You can’t look directly at them as these files are binary ones. You need two commands to analyse the audit log. One to extract the data out of the log files based on certain rules and one command to translate it into a human readable format. You use the auditreduce command for the first step, and the praudit command for the second one.
# cd /var/audit/aragorn-sol
auditreduce * | praudit -s
This sequence of commands translates all your audit logs into a human readable form. I’ve cut out some of the lines for an example:
header,69,2,AUE_ssh,,localhost,2008-02-01 23:49:17.687 +01:00
subject,jmoekamp,jmoekamp,other,jmoekamp,other,720,3447782834,6969 5632 10.211.55.2
return,success,0
header,77,2,AUE_su,,localhost,2008-02-01 23:49:55.336 +01:00
subject,jmoekamp,root,other,jmoekamp,other,729,3447782834,6969 5632 10.211.55.2
text,root
return,failure,Authentication failed
header,69,2,AUE_su,,localhost,2008-02-01 23:50:11.311 +01:00
subject,jmoekamp,root,root,root,root,730,3447782834,6969 5632 10.211.55.2
return,success,0
What does this snippet tell you: I’ve logged into my system as the user jmoekamp, tried to assume root privileges, failed the first time (due to a wrong password), tried it again and succeeded.
More auditing
Sometimes it’s important to know what users have done on your system. For example: Which programs have been executed. With Solaris auditing it’s really easy to collect this information.
At first you have to configure auditing to collect this kind of information:
dir:/var/audit/aragorn-sol
flags:lo,ex
minfree:20
naflags:lo,ex
The ex audit class matches all events in the system in regard to the execution of a program. This tells the auditing subsystem to log all execve() system calls. But you have to signal this change to the audit subsystem to start the auditing of these events. With audit -s you notify the audit daemon to read the /etc/security/audit_control file again.
header,113,2,AUE_EXECVE,,localhost,2008-02-02 00:10:00.623 +01:00
path,/usr/bin/ls
attribute,100555,root,bin,26738688,1380,0
subject,jmoekamp,root,root,root,root,652,2040289354,12921 71168 10.211.55.2
return,success,0
But this configuration only logs the path of the command, not the command line parameters. You have to configure it to log this information. You remember: The audit policy controls the kind of information in the audit logs. Thus we have to modify the audit policy. With the command auditconfig -setpolicy +argv you change the policy. You don’t have to activate it, it’s immediately effective:
header,124,2,AUE_EXECVE,,localhost,2008-02-02 00:12:49.560 +01:00
path,/usr/bin/ls
attribute,100555,root,bin,26738688,1380,0
exec_args,2,ls,-l
subject,jmoekamp,root,root,root,root,665,2040289354,12921 71168 10.211.55.2
return,success,0
To make this behavior persistent, you have to add the auditconfig -setpolicy +argv to the /etc/security/audit_startup file.
Want to learn more?
This is only a really short introduction to the topic. You will find the documentation for this feature at docs.sun.com: Part VII Solaris Auditing is a good place to start.
(review: 2026-04-12)