You have allowed junior to edit the httpd.conf via pfedit and and some nice evening, you are sitting at home. Then: You get alerts on your mobile: Webserver down. You log into the server. You check the httpd.conf. You see an error. You correct it. You look into the change log. Nothing. You ask your colleagues, who made this change. Nobody. Dang. Now you have a classic “Whodunit” at hand.

Okay, in order to prevent such situations in the future, you want to record this kind of information. And using pfedit can really help you doing so. Because auditing is integrated into pfedit.

In the audit log

In my last pfedit blog entry i demonstrated, how you could delgate the privileges to edit a file to a non-privileged user.

Edits by pfedit are audited via the as calls. So you could filter you filter your audit log for this class:

 
root@testbed:~# auditreduce -c as | praudit

There will be probably a lot of entries. However after using pfedit you should see something like this.

 
header,528,2,edit administrative file,,testbed,2025-04-13 05:21:20.232+02:00
subject,junior,root,staff,junior,staff,1721,3672097120,148 2 Mac
groups,staff
path,/etc/apache2/2.4/httpd.conf
use of authorization,solaris.admin.edit/etc/apache2/2.4/httpd.conf
text,--- /etc/apache2/2.4/httpd.conf	2024-07-05 09:14:14.248741487 +0200
     +++ /etc/apache2/2.4/httpd.conf.pfedit.6SCRJc	2025-04-13 05:21:20.224337759 +0200
     @@ -8,6 +8,7 @@
      #
      # Solaris Quick Configuration Information
      #
     +#
      # 1. Set ServerName if necessary (default is 127.0.0.1)
      # 2. Set ServerAdmin to a valid email address
      #
     
return,success,0
zone,global

There is actually a diff in the audit log. You could use other filtering rules as well. For example to see all audit entries for using the authorization to edit the /etc/apache2/2.4/httpd.conf file.

 
root@testbed:~# auditreduce -o auth=solaris.admin.edit/etc/narf.conf | praudit 

Wondering

However then i thought: “Wait a moment, i didn’t edited the profile for editing the httpd.conf file to activate auditing of this class. Why is the system already showing the auditing records for this the class?”

The answer is relatively simple: The statistics store in Oracle Solaris consumes a number of audit classes. Those classes are summarized in a meta class called sstore. This meta class contains a number of audit classes: lo, ss, pe, cy and finally as.

When you look at the configured audit classes, you fill find this meta class sstore. This was the default on my system:

 
root@testbed:~# auditconfig -getflags 
configured user default audit flags = sstore,ua(0x200079000,0x200079000)
active user default audit flags = sstore,ua(0x200079000,0x200079000)

By having the sstore class configured, the administrative edits found their way into my audit log because this meta class contains as.

On a system without this statstore class (which probably means you are running a much older system than you should) you have to add this for example to the profile we assigned to the user junior to enable the user to edit the file.

 
root@testbed:/etc/security# profiles -p "httpd edit"
profiles:httpd edit> info
	name=httpd edit
	desc=Edit httpd
	auths=solaris.admin.edit/etc/apache2/2.4/httpd.conf,solaris.admin.edit/etc/apache2/2.4/mime.types,solaris.admin.edit/etc/narf.conf
profiles:httpd edit> add always_audit=as
profiles:httpd edit> info
	name=httpd edit
	desc=Edit httpd
	auths=solaris.admin.edit/etc/apache2/2.4/httpd.conf,solaris.admin.edit/etc/apache2/2.4/mime.types,solaris.admin.edit/etc/narf.conf
	always_audit=as
profiles:httpd edit> exit