SpamAssassin Log explosion issue following update

[Daniel J Walsh]

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
> # 
>
>
>
>