Playing with selinux today.

A script in cron – ran by root – wasn’t able to create a file into a directory. SELinux reported:

…denied { dac_override }
… scontext=system_u:system_r:mrtg_t
… tcontext=system_u:system_r:mrtg_t

And the syscall in error was open(“/var/lock/mrtg/mrtg.lock”, …)

…
syscall=2 success=no exit=-13
…
auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none)
…
comm=”mrtg”
subj=system_u:system_r:mrtg_t

The first thing I noted is that running the mrtg script by hand, as a root user, didn’t cause any error.
And as the scontext and tcontext were the same, I excluded a selinux-context issue.

So I search something more about the dac_override capability: it’s shortly the passe-par-tout ability that root have to bypass the standard user permissions. A user running the mrtg script can’t enjoy that feature, because:
* mrtg is in the mrtg_t domain

# ls -lZ /usr/bin/mrtg
-rwxr-xr-x. root root system_u:object_r:mrtg_exec_t:s0 /usr/bin/mrtg

* the mrtg_t domain hasn’t dac_override capability

# sesearch –allow -s mrtg_t | grep dac_

Besides, the unconfined_t domain has that capability

# sesearch –allow -s unconfined_t | grep dac_
allow unconfined_t unconfined_t : capability { chown dac_override dac_read_search …} ;

At this point I checked if the directory permission was consistent with the original package:

#rpm -V mrtg
…..UG.. /var/lock/mrtg

After resetting that value to the original one, everything went fine.

rpm -qlv mrtg |grep lock
drwxr-xr-x 2 root root 0 Nov 11 2010 /var/lock/mrtg

Another solution (which is not a good idea ;P) would have been to grant the dac_override capability to mrtg, following the hints given by audit2allow.

SE_ERROR_ID=1343401202.394:2446
grep $SE_ERROR_ID /var/log/audit/audit.log | audit2allow
#============= mrtg_t ==============
allow mrtg_t self:capability dac_override;