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
#
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
