Red Hat Bugzilla – Bug 425958
spamass-milter generates AVC errors
Last modified: 2008-01-29 04:03:43 EST
Description of problem: Spamass-milter generates SELINUX related warnings. Packages should include appropriate SELINUX configs. ---- message follows ----- sealert -l aaef901b-9744-44c2-89f0-f4b58b29815c Summary SELinux is preventing sendmail (sendmail_t) "connectto" to /var/run/spamass- milter/spamass-milter.sock (initrc_t). Detailed Description SELinux denied access requested by sendmail. It is not expected that this access is required by sendmail and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access You can generate a local policy module to allow this access - see http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package. Additional Information Source Context system_u:system_r:sendmail_t:s0 Target Context system_u:system_r:initrc_t:s0 Target Objects /var/run/spamass-milter/spamass-milter.sock [ unix_stream_socket ] Affected RPM Packages Policy RPM selinux-policy-3.0.8-64.fc8 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Permissive Plugin Name plugins.catchall Host Name xxxxxx Platform Linux xxxxxx 2.6.23.1-42.fc8 #1 SMP Tue Oct 30 13:18:33 EDT 2007 x86_64 x86_64 Alert Count 28 First Seen Sun Dec 9 10:32:04 2007 Last Seen Mon Dec 17 07:12:25 2007 Local ID aaef901b-9744-44c2-89f0-f4b58b29815c Line Numbers Raw Audit Messages avc: denied { connectto } for comm=sendmail path=/var/run/spamass-milter /spamass-milter.sock pid=24929 scontext=system_u:system_r:sendmail_t:s0 tclass=unix_stream_socket tcontext=system_u:system_r:initrc_t:s0
This appears to be a labelling problem. /var/run/spamass-milter /spamass-milter.sock should be spamd_var_run_t, not initrc_t. Try stopping the milter and sendmail, remove /var/run/spamass-milter /spamass-milter.sock if it exists, then do: # restorecon -rv /var/run/spamass-milter Then try starting the services again.
Been there, done that. No change.
OK, so what contexts have you got? $ ls -lZd /var/run $ ls -laZ /var/run/spamass-milter What about sestatus? $ sestatus -v Are you starting spamass-milter using the provided initscript?
I'm bitten by this as well. It's due to the fact that /usr/sbin/spamass-milter has a selinux type of bin_t, which when run from an init script, becomes initrc_t, which changes the type of the socket it opens (/var/run/spamass-milter/spamass-milter.sock) to become initrc_t, despite its label of spamd_var_run_t. That can be fixed by running: chcon -t spamd_exec_t /usr/sbin/spamass-milter Sendmail would then be able to connect to the socket. HOWEVER, when run as spamd_exec_t, spamass-milter can't execute spamc, which makes spamass-milter useless. spamass-milter may need its own selinux type that sendmail can connect to, and can execute spamc. Or add a rule that spamd_exec_t can execute spamc, but spamd never does this, so that wouldn't be particularly ideal.
I've raised this problem on fedora-selinux-list (https://www.redhat.com/archives/fedora-selinux-list/2008-January/msg00007.html) but nobody has responded yet :-(
Dan has committed a fix for this in cvs for selinux-policy 3.0.8-78. It may be a few days yet before it gets built and appears in updates-testing. I intend to write a separate selinux policy for spamass-milter (and also for milter-regex), which will need a lot of testing. I'd be very happy to hear from anyone willing to help with this, particularly if you have a more "unusual" configuration such as running over network sockets rather than unix domain sockets, or using postfix instead of sendmail.
selinux-policy-targeted-3.0.8-81.fc8 from updates-testing fixes this for me. # yum --enablerepo=updates-testing update selinux\*
selinux-policy-targeted-3.0.8-81.fc8 has now been pushed to the updates repository; a regular yum update will fix this problem once the mirrors have synced.