Ted Rule wrote:
I recently updated SpamAssassin on my FC6/strict box to spamassassin-3.1.8-2.fc6.
FWIW, the selinux-policy is currently on selinux-policy-strict-2.4.6-37.fc6
It seems that the installation may well have partially failed because I ran "yum update spamassassin" whilst still in enforcing mode.
I erroneously assumed that spamd continued to run Ok, as I saw no error messages during the "yum update".
Sadly, to my horror earlier today, I found that the /var partition was completely full of log messages from SELinux/spamd, viz:
... Feb 22 12:08:25 topaz kernel: audit(1172146105.931:9462050): avc: denied { search } for pid=10329 comm="spamd" name="/" dev=hda2 ino=2 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir Feb 22 12:08:25 topaz kernel: audit(1172146105.932:9462051): avc: denied { search } for pid=10329 comm="spamd" name="/" dev=hda2 ino=2 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir Feb 22 12:08:25 topaz kernel: audit(1172146105.932:9462052): avc: denied { search } for pid=10329 comm="spamd" name="/" dev=hda2 ino=2 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir Feb 22 12:08:25 topaz kernel: audit(1172146105.932:9462053): avc: denied { search } for pid=10329 comm="spamd" name="/" dev=hda2 ino=2 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir ....
In other words, for some reason the "broken" update left the process running in the unlabeled_t domain, which is a little bizarre.
In any event, I then got a continuous stream of these denials in the log which eventually filled the log within a few hours.
Note to self: presumably using auditd instead of syslog-ng for storing these messages would have avoided the filesystem overload. Similarly, I have yet to check the manual pages for syslog-ng for a max-logfile-size option which might have avoided the ensuing embarrassment.
After clearing out the massive log files to give spamd and syslog-ng room to manoeuvre, I then tried looking for the spamd[10329] in the process list, but found that it was invisible(!), presumably because it was running as unlabeled_t.
I then tried temporarily enabling the "allow_ptrace" boolean to see if that helped make the process visible, to no avail.
Finally, I was forced to drop into permissive mode to locate the rogue PID running in "unlabeled_t".
So then I stopped spamd, went back to enforcing mode, and restarted spamd, which duly ran in its proper spamd_t domain.
From previous experiences I think the strict policy, and perhaps the
targeted policy also, is missing several permissions which allow various init scripts to be called from within "yum update".
To satisfy my own curiousity, can someone explain how spamd ended up running in unlabeled_t? Is it somehow related to a process continuing to run which has no corresponding executable binary?
Following this experience, can I make some suggestions:
a. Please test that rpm/yum update runs without error for any RPM update on both a strict/enforcing box and a targeted/enforcing box before the RPM is released to mirrors.
I have no idea what caused this. The usually example would be that your program spamd was running in a context that was removed from the system. So say you had it running in a local policy myspamd_t and then you removed the policy, it would end up in unlabeled_t. Nothing in this update should have caused this.
b. Don't expect that yum update can be run in enforcing mode, especially on packages associated with running daemons.
It should be able to run in enforcing mode. The only thing I am aware of where this has been a problem was in MLS machines where you have to run run_init yum -y upgrade.
c. Please can we add a policy permission so that sysadm_t can seek and destroy unlabeled_t processes with extreme prejudice without recourse to permissive mode?
I agree this policy will be added.
Ted
# ps axf | grep 103 14549 pts/1 S+ 0:00 _ grep 103 # setsebool allow_ptrace=1 # getsebool -a| grep ptrace allow_ptrace --> on # ps axf | grep 103 14561 pts/1 S+ 0:00 _ grep 103
# setenforce 0 # ps axf | grep 103 10329 ? Ss 12:44 /usr/bin/spamd -d -c -m5 -H -r /var/run/spamd.pid 10331 ? Z 1:23 _ [spamd] <defunct> 10332 ? Z 0:06 _ [spamd] <defunct> 14564 pts/1 S+ 0:00 _ grep 103 # ps axfZ | grep 103 system_u:object_r:unlabeled_t 10329 ? Ss 12:44 /usr/bin/spamd -d -c -m5 -H -r /var/run/spamd.pid system_u:object_r:unlabeled_t 10331 ? Z 1:23 _ [spamd]
<defunct> system_u:object_r:unlabeled_t 10332 ? Z 0:06 \_ [spamd] <defunct> staff_u:sysadm_r:sysadm_t 14566 pts/1 S+ 0:00 \_ grep 103 # setenforce 1 # ps axfZ | grep 103 staff_u:sysadm_r:sysadm_t 14569 pts/1 S+ 0:00 \_ grep 103
# setenforce 0 # run_init service spamassassin stop Authenticating root. Password: Stopping spamd: [ OK ] # ps axf | grep spam 14591 pts/1 S+ 0:00 _ grep spam
# setenforce 1 # run_init service spamassassin start Authenticating root. Password: Starting spamd: [ OK ] # ps axfZ | grep spam staff_u:sysadm_r:sysadm_t 14617 pts/1 S+ 0:00 _ grep spam system_u:system_r:spamd_t 14612 ? Ss 0:01 /usr/bin/spamd -d -c -m5 -H -r /var/run/spamd.pid system_u:system_r:spamd_t 14614 ? S 0:00 _ spamd child system_u:system_r:spamd_t 14615 ? S 0:00 _ spamd child #