I´m using pfedit quite frequently. However i learned about one option only when i reviewed the old blog entry for re-publication in the last few days. In the last blog entry i showed to you that pfedit puts a diff of your changes to the audit log. But sometimes you don’t want this. Especially if you transport your audit logs off-system for further analysis. E.g. files with credentials in it. You don’t want to have those credentials on other systems you don’t have under your control.
root@testbed:~# profiles -p "httpd edit"
profiles:httpd edit> add auths=solaris.admin.edit/etc/narf.conf
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
never_audit=no
profiles:httpd edit> exitThe file /etc/narf.conf doesn’t exist at the moment. When using pfedit /etc/narf.conf it will be created. However when you are using the -s option, the process creates a file that is a little bit special. At first the file is created owned by user root and group root and only read- and writeable by the user root.
root@testbed:/etc/security# ls -l /etc/narf.conf
-rw------- 1 root root 13 Apr. 13 10:19 /etc/narf.confHowever, in addition to this it’s created with the attribute sensitive:
root@testbed:/etc/security# ls -/v /etc/narf.conf
-rw------- 1 root root 13 Apr. 13 10:19 /etc/narf.conf
{archive,nohidden,noreadonly,nosystem,noappendonly,nonodump,noimmutable,av_modified,noav_quarantined,nonounlink,nooffline,nosparse,sensitive}This attribute grants the file an exception from the standard behaviour of pfedit:
header,173,2,edit administrative file,,testbed,2025-04-13 16:04:20.796+02:00
subject,junior,root,staff,junior,staff,2541,3672097120,148 2 Mac
groups,staff
path,/etc/narf.conf
use of authorization,solaris.admin.edit/etc/narf.conf
return,success,0
zone,globalThe diff with the potential sensitive information isn’t in the audit log, thus keeping this information from the rest of the chain processing your audit log files.
You can set this sensitive attribute for other files as well. I will use a file with an already exiting authorization{^1}:
root@testbed:/etc/apache2/2.4# ls -/v mime.types
-rw-r--r-- 1 root bin 60952 März 26 06:52 mime.types
{archive,nohidden,noreadonly,nosystem,noappendonly,nonodump,noimmutable,av_modified,noav_quarantined,nonounlink,nooffline,nosparse,nosensitive}
root@testbed:/etc/apache2/2.4# chmod S+vsensitive mime.types
root@testbed:/etc/apache2/2.4# ls -/v mime.types
-rw-r--r-- 1 root bin 60952 März 26 06:52 mime.types
{archive,nohidden,noreadonly,nosystem,noappendonly,nonodump,noimmutable,av_modified,noav_quarantined,nonounlink,nooffline,nosparse,sensitive}After adding a comment into the file, we check the audit log for entries.
root@testbed:/etc/apache2/2.4# auditreduce -o auth=solaris.admin.edit/etc/apache2/2.4/mime.types | praudit
(...)
header,199,2,edit administrative file,,testbed,2025-04-13 16:14:17.241+02:00
subject,junior,root,staff,junior,staff,2567,3672097120,148 2 Mac
groups,staff
path,/etc/apache2/2.4/mime.types
use of authorization,solaris.admin.edit/etc/apache2/2.4/mime.types
return,success,0
zone,globalThe diff is missing here as well.
Of course, you can’t just change the attribute to get the diff back into the audit file when you only have the authorization to edit it.
junior@testbed:~$ chmod S-vsensitive /etc/narf.conf
chmod: ERROR: cannot set the following attributes on /etc/narf.conf: not privileged
{nosensitive}With a sufficiently privileged user, you don’t have this problem.
root@testbed:~# chmod S-vsensitive /etc/narf.conf
root@testbed:~#
