Description of problem: After an upgrade from F8, service spamass-milter refuses to start Version-Release number of selected component (if applicable): spamass-milter-0.3.1-7.fc9.i386 How reproducible: Always Steps to Reproduce: 1.service spamass-milter start Starting SpamAssassin milter (spamass-milter): [ OK ] 2.service spamass-milter status spamass-milter dead but pid file exists 3.service spamass-milter stop Shutting down SpamAssassin milter (spamass-milter): [FAILED] Actual results: mail box flooded with (see attachment) messages Expected results: spamass-milter working properly Additional info: It worked fine on F8. I investigated a bit and I suspect there is a permission problem when spamass-milter try to create the pidfile (spamass-milter.pid) on /var/run/ directory, as sa-milt user.
Created attachment 305893 [details] Mail from spamassassin-milter
Created attachment 305894 [details] Mail from spamassassin-milter
This appears to be an selinux issue; doing "setenforce 0" allows the service to start here. I'll look into a proper fix for this, which will probably involve a change to policy.
I can confirm is a selinux issue: the service run OK with selinux in permissive mode
My proposed fix is this: Add a context to selinux-policy, equivalent to doing: semanage fcontext -a -t spamd_var_run_t -f -- /var/run/spamass-milter\.pid Make the following change to the initscript: --- /etc/rc.d/init.d/spamass-milter.orig 2008-05-20 12:48:02.000000000 +0100 +++ /etc/rc.d/init.d/spamass-milter 2008-05-20 12:38:24.000000000 +0100 @@ -44,6 +44,9 @@ echo -n $"Starting ${desc} (${prog}): " touch ${pidfile} chown sa-milt:sa-milt ${pidfile} + if [ -x /usr/sbin/selinuxenabled ] && /usr/sbin/selinuxenabled; then + /sbin/restorecon ${pidfile} + fi daemon --user sa-milt /usr/sbin/${prog}-wrapper -p ${SOCKET} -P ${pidfile} ${EXTRA_FLAGS} RETVAL=$? echo The restorecon snippet here is similar to the one in the sendmail initscript for creating the sm-client pidfile. Dan, does this look sensible?
Yes I am adding the file context I would just add [ -x /sbin/restorecon ] && /sbin/restorecon ${pidfile} Restorecon checks whether selinux is enabled internally. Policy selinux-policy-3.3.1-53 has the fix.
Does restorecon exit silently with 0 exit status if selinux is disabled?
From setfiles.c (restorecon) /* restorecon only: silent exit if no SELinux. Allows unconditional execution by scripts. */ if (is_selinux_enabled() <= 0) exit(0);
spamass-milter-0.3.1-8.fc9 has been submitted as an update for Fedora 9
Packages are now built and awaiting the push to testing. For now, you can get them here: selinux-policy: http://koji.fedoraproject.org/koji/buildinfo?buildID=49920 spamass-milter: http://koji.fedoraproject.org/koji/buildinfo?buildID=49928
spamass-milter-0.3.1-8.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update spamass-milter'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-4368
Esteban, is spamass-milter actually running OK for you? I'm getting loads of SELinux denials now that I'm on Fedora 9 with my mail server, as spamass-milter, which runs in SELinux context type spamd_t, calls spamc, which isn't currently provided for in policy. I think I may be better off writing a custom policy for spamass-milter.
Check out in selinux-policy-3.3.1-55.fc9 there were some fixes for this.
Paul: So far so good: I updated selinux-policy & spamass-milter, as suggested in Comment #10, and that was enough to fix the problem. Right now I have spamass-milter-0.3.1-8.fc9.i386 selinux-policy-3.3.1-55.fc9.noarch selinux-policy-devel-3.3.1-55.fc9.noarch selinux-policy-targeted-3.3.1-55.fc9.noarch installed, and spamass-milter is working fine without any avc denial detected.
(In reply to comment #13) > Check out in selinux-policy-3.3.1-55.fc9 > > there were some fixes for this. I'm already using selinux-policy-3.3.1-55.fc9; it fixes the startup problem but I got loads of new AVCs that resulted in these rules: # spamass-milter calling spamc? spamassassin_exec_client(spamd_t) sendmail_rw_tcp_sockets(spamc_t) sendmail_rw_unix_stream_sockets(spamc_t) spamassassin_read_lib_files(spamc_t) corenet_tcp_connect_spamd_port(spamd_t) I'm still getting some other AVCs that I've not investigated yet: type=AVC msg=audit(1211929219.971:3510): avc: denied { execute } for pid=26003 comm="spamass-milter" name="bash" dev=dm-0 ino=80018 scontext=system_u:system_r:spamd_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file type=SYSCALL msg=audit(1211929219.971:3510): arch=40000003 syscall=11 success=no exit=-13 a0=92023f a1=b4343194 a2=bfd518a8 a3=3 items=0 ppid=6189 pid=26003 auid=4294967295 uid=496 gid=495 euid=496 suid=496 fsuid=496 egid=495 sgid=495 fsgid=495 tty=(none) ses=4294967295 comm="spamass-milter" exe="/usr/sbin/spamass-milter" subj=system_u:system_r:spamd_t:s0 key=(null) I think this one is triggered in a "learn as spam" situation. It looks far too dangerous to allow though. type=AVC msg=audit(1211929514.578:3547): avc: denied { append } for pid=26302 comm="spamc" path="/home/paul/.nospam/procmail.log" dev=dm-12 ino=3148799 scontext=system_u:system_r:spamc_t:s0 tcontext=system_u:object_r:user_home_t:s0 tclass=file type=SYSCALL msg=audit(1211929514.578:3547): arch=40000003 syscall=11 success=yes exit=0 a0=bffde3c3 a1=83dc928 a2=83dcc58 a3=83dc520 items=0 ppid=26301 pid=26302 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=4294967295 comm="spamc" exe="/usr/bin/spamc" subj=system_u:system_r:spamc_t:s0 key=(null) Either or both of these (and maybe even the ones I've done the local rules for above) might actually be coming from my procmail rules rather than spamass-milter - I have rules that feed mail into spamc for learning when my own hand-rolled procmail-based spam filter is convinced that a message is spam. I'll try disabling those rules and see if the AVCs go away.
I think I've found the shell exec: if you use the -b or -B options in spamass-milter to redirect spam to a specific mailbox, the milter opens a pipe with popen() and calls sendmail to deliver the message. I really do think a separate policy is going to be needed here rather than sharing spamd_t with spamassassin.
Paul: My bad: Comment #12 is correct. Spamass-milter is flooding logs w/avc denials. I didn't remember the fact that I had (from F8) a local policy enabled in order to get rid of them (see attachment myspam.te ). If I remove the policy, I get lots of avc denials I guess I will keep the local policy until the fix of Comment #16 is finished
Created attachment 307262 [details] Local policy for spmassassin avcs
I posted my first pass at a new policy for spamass-milter (and milter-regex too) here: http://www.redhat.com/archives/fedora-selinux-list/2008-June/msg00007.html Using this policy, I've not had a single AVC related to mail since I installed it a couple of days ago. Since it separates spamass-milter from spamassassin so that they are separately confined, there are currently some conflicts in the file contexts with the main selinux-policy package that result in warnings though they don't actually cause any problems that I can see. If you want to try the new policy (and I'd appreciate feedback on it), you'll need to change the contexts of /usr/sbin/spamass-milter and /var/run/spamass-milter and its contents after installing the policy (restorecon -rv should work), and then restart the milter.
spamass-milter-0.3.1-8.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
I've updated my SELinux policy for spamass-milter: see Bug #452248 I'm in the process of trying to get the policy updated in selinux-policy upstream.
Reopening since there are still issues with SELinux here. I have requested that my milter SELinux policy module be added to Fedora 9 and 10 policy (it is already in Rawhide) in Bug #483849
spamass-milter-0.3.1-13.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/spamass-milter-0.3.1-13.fc10
spamass-milter-0.3.1-13.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/spamass-milter-0.3.1-13.fc9
spamass-milter-0.3.1-13.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
spamass-milter-0.3.1-13.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.