SELinux doesn't understand sendmail<->spamassassin interactions

[Paul Howarth]

G.Wolfe Woodbury wrote:
> Paul Howarth wrote:
>> On Wed, 18 Feb 2009 17:53:41 -0500
>> "G.Wolfe Woodbury" <ggw at wolves.durham.nc.us> wrote:
>>
>>> Similar to the mailman problem, SELinux doesn't understand the 
>>> interactions between sendmail and spamassassin.  In this case,
>>> however, the spamassassin stuff quits working completely.
>>>
>>> This installation of spamassassin uses the "spamc" daemon, and mails
>>> are passed to that daemon from user's .procmailrc files. (This allows
>>> the user to opt-in/opt-out of spam detection on their own by altering
>>> their own .procmailrc file.)
>>>
>>> SELinux complains a lot because every message passwd from the user 
>>> delivery chain gets a denial because "sendmail" (actually procmail)
>>> has no permissions to write the spamassassin spamc socket:
>>>
>>> type=AVC msg=audit(1234094494.975:3163): avc:  denied  { read write }
>>> for  pid=612 comm="spamc" path="socket:[2166561]" dev=sockfs
>>> ino=2166561 scontext=system_u:system_r:spamc_t:s0 
>>> context=system_u:system_r:sendmail_t:s0
>>> tclass=unix_stream_socket
>>
>> This is actually spamc failing to read/write a sendmail socket and is
>> most likely to be a leaked file descriptor in the sendmail local
>> delivery process, as per Bug #485426. Do you have *any* milters in your
>> sendmail config?
> 
> Well, there is a clamav-milter in place to check incoming mail for 
> viruses as some users read mail via OE and Windows Thunderbird.  This 
> has never been a problem on this system.
> 
> My point is that spamc is doing operations in a sendmail context because 
> sendmail is calling procmail to do local delivery and the first entry in 
> most user .procmailrc filter lists is a pipe to/from spamc.  The context 
> is two execs removed from sendmail itself.  The policy simply doesn't 
> recognize that a sendmail context is calling spamc several hundred times 
> a day.

I disagree; the AVC above shows a process running in spamc_t failing to 
read/write a socket that's sendmail_t. So sendmail will have 
transitioned via procmail_t in the local delivery process and then on to 
spamc_t from there. I believe that these denials are from a leaked 
socket descriptor that sendmail uses to communicate with clamav-milter, 
and I don't think these are the cause of the problem you're getting in 
enforcing mode. You could test this theory by briefly disabling 
sendmail's use of clamav-milter and seeing if the AVCs appear next time 
mail comes in.

>>> I don't fully understand some of the concepts used in SELinux, and am 
>>> running F10+updates in "permissive" mode so that things work but I
>>> get notified of "abnormal" events.
>>>
>>> Additionally, other aspects of the sendmail/spamassassin interaction 
>>> attract SELinux complaints. (getattr of spamc socket, etc) but I geet 
>>> thousands of complaints about the read/write of the spamc socket.
>>> (about 8 active e-mail accounts, several of which are spam traps.)
>>>
>>> Thanks for your attention and patience.
>>
>> Can you post examples of the other denials you get?
>>
>> Paul.
> 
> On closer examination, there are no other spamassassin/sendmail AVCs.
> I have a few clamav-sendmail context AVCs, but that are 6 a day vs. 1200 
> a day for the spamc AVCs.
> 
> Actually reading through the selinux trapper messages is making some 
> things clearer.  I'm now more convinced that this is a policy issue 
> rather than a bug.

If things break when you're in enforcing mode and you're not doing 
something very unusual or silly (which doesn't seem to be the case), 
then yes, that'll be a policy bug.

If you can test whether my theory about the leaked file descriptors is 
right, and it shows that I am, you could use a local policy module to 
make those AVCs go away and then it might be easier to spot the problem 
that's actually breaking things for you in enforcing mode.

Paul.