SpamAssassin Log explosion issue following update

[Ted Rule]

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.

b. Don't expect that yum update can be run in enforcing mode, especially
on packages associated with running daemons.

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?




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
# 



-- 
Ted Rule

Director, Layer3 Systems Ltd

W: http://www.layer3.co.uk/