Spamassassin + Procmail + Lockfile + SELinux = broken

[mothra]

Thanks Paul and Daniel:

My procmail invocation is:

       :0fw
       * < 256000
       | /usr/bin/spamassassin

And I see that I'm missing the lock (:) on this one, so I think my
comment about procmail writing a lockfile was in error.  I looked into
spamc as an alternative - seems to work without a problem.  Thanks for the
tip Paul.

The OS is Fedora Core 5, which I've been (somewhat blindly) updating with
yum (no extra configuration on yum - just running it out of the box).  Yum
never complained, so I did not suspect that the system was partially
upgraded.  To be explicit, I've not yet tried to upgrade to FC6 or FC7.
For the record, current status is

           [root at parsnip ~]# rpm -qa | grep policy
           selinux-policy-2.3.7-2.fc5
           selinux-policy-targeted-2.3.7-2.fc5
           policycoreutils-1.30.10-2.fc5

I guess the urgency on this is pretty low now that I've got the filter up
and running (via spamc). But I'm still curious as to what I would have to
have done if spamc didn't exist. I'm concerned about how many more SELinux
bullets I can dodge...  :)


>I'm rather green, and have had some trouble deciphering a lot of the
>SELinux stuff.  Any help would be great.  I'm using procmail to filter
>mail through spamassassin (SA), but SELinux appears to be interfering.  I
>say this because if I turn off enforcing, mail gets through properly
>tagged by SA.  With SELinux on, messages are not tagged by SA.  The log
>looks like this:
>
>Jun 26 23:07:51 parsnip kernel: audit(1182917271.036:1779): enforcing=1
>old_enforcing=0 auid=4294967295
>Jun 26 23:07:51 parsnip dbus: avc:  received setenforce notice 
>(enforcing=1)
>Jun 26 23:08:04 parsnip kernel: audit(1182917284.795:1780): avc:  denied 
>{ search } for  pid=28116 comm="spamassassin" name="tmp" dev=sda3
>ino=26738689 scontext=user_u:system_r:procmail_t:s0
>tcontext=system_u:object_r:tmp_t:s0 tclass=dir
>
>My (rather ignorant) read is that procmail_t and tmp_t are not matching
>(procmail does try to write a lockfile).  And what I have gleaned is that
>I either need some sort of rule that somehow matches these two, or I need
>to change some tags (on my /tmp directory?) to allow this to proceed.
>
>Am I anywhere near the ballpark?  I tried audit2why to decipher this, but
>it complained that it didn't understand policies outside of the range
>15-20.  Audit2allow returns
>
>                     allow procmail_t tmp_t:di search;
>
>But I'm not sure what to do with it...
>
>Thanks in advance for any help!
>
>- Lowell