Red Hat Bugzilla – Bug 624546
Spam reporting through Horde application framework to Spamassassin ends up in AVC denial
Last modified: 2010-08-31 02:39:04 EDT
First of all, all credit for solving this goes to dgrift on #fedora-selinux. He also told me to file this bug. Description of problem: This is a default installation of Postfix, Procmail, Spamassassin and Dovecot with a couple of spam filtering rules. Running Horde (Horde Application framework with Imp, www.horde.org) on httpd-2.2.16-1.fc13.i686 and php-5.3.2-2.fc13.i686. When I receive spam and flag it with "Report as spam" -button, Horde sends it to /usr/bin/spamassassin -r. User gets no errors, but there are multiple AVC denials in /var/log/messages. Also, the spam message is not really flagged as spam. /var/log/messages: Aug 16 19:32:25 triton setroubleshoot: SELinux is preventing /usr/bin/perl "getattr" access on /var/lib/spamassassin/3.003001/updates_spamassassin_org.cf. For complete SELinux messages. run sealert -l f263b72a-9f8c-4218-b767-ad5acd7117b5 Aug 16 19:32:25 triton setroubleshoot: SELinux is preventing /usr/bin/perl "getattr" access on /var/lib/spamassassin/3.003001/sought_rules_yerp_org.cf. For complete SELinux messages. run sealert -l f263b72a-9f8c-4218-b767-ad5acd7117b5 Aug 16 19:54:27 triton setroubleshoot: SELinux is preventing /usr/bin/perl "getattr" access on /var/lib/spamassassin/3.003001/updates_spamassassin_org.cf. For complete SELinux messages. run sealert -l f263b72a-9f8c-4218-b767-ad5acd7117b5 Aug 16 19:54:27 triton setroubleshoot: SELinux is preventing /usr/bin/perl "getattr" access on /var/lib/spamassassin/3.003001/sought_rules_yerp_org.cf. For complete SELinux messages. run sealert -l f263b72a-9f8c-4218-b767-ad5acd7117b5 Aug 16 19:55:02 triton setroubleshoot: SELinux is preventing /usr/bin/perl "getattr" access on /var/lib/spamassassin/3.003001/updates_spamassassin_org.cf. For complete SELinux messages. run sealert -l f263b72a-9f8c-4218-b767-ad5acd7117b5 Aug 16 19:55:02 triton setroubleshoot: SELinux is preventing /usr/bin/perl "getattr" access on /var/lib/spamassassin/3.003001/sought_rules_yerp_org.cf. For complete SELinux messages. run sealert -l f263b72a-9f8c-4218-b767-ad5acd7117b5 Aug 16 19:55:03 triton setroubleshoot: SELinux is preventing /usr/bin/perl "getattr" access on /var/lib/spamassassin/3.003001/updates_spamassassin_org.cf. For complete SELinux messages. run sealert -l f263b72a-9f8c-4218-b767-ad5acd7117b5 Aug 16 19:55:03 triton setroubleshoot: SELinux is preventing /usr/bin/perl "getattr" access on /var/lib/spamassassin/3.003001/sought_rules_yerp_org.cf. For complete SELinux messages. run sealert -l f263b72a-9f8c-4218-b767-ad5acd7117b5 Aug 16 19:57:30 triton setroubleshoot: SELinux is preventing /usr/bin/perl "getattr" access on /var/lib/spamassassin/3.003001/updates_spamassassin_org.cf. For complete SELinux messages. run sealert -l f263b72a-9f8c-4218-b767-ad5acd7117b5 Aug 16 19:57:30 triton setroubleshoot: SELinux is preventing /usr/bin/perl "getattr" access on /var/lib/spamassassin/3.003001/sought_rules_yerp_org.cf. For complete SELinux messages. run sealert -l f263b72a-9f8c-4218-b767-ad5acd7117b5 Output from "ausearch -m avc -ts recent": type=SYSCALL msg=audit(1281984499.824:3513896): arch=40000003 syscall=195 success=no exit=-13 a0=93f1858 a1=93910c0 a2=4cfff4 a3=9391008 items=0 ppid=28409 pid=29745 auid=500 uid=48 gid=488 euid=48 suid=48 fsuid=48 egid=488 sgid=488 fsgid=488 tty=(none) ses=180 comm="spamassassin" exe="/usr/bin/perl" subj=unconfined_u:system_r:httpd_t:s0 key=(null) type=AVC msg=audit(1281984499.824:3513896): avc: denied { search } for pid=29745 comm="spamassassin" name="spamassassin" dev=md2 ino=411678 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=system_u:object_r:spamd_var_lib_t:s0 tclass=dir Version-Release number of selected component (if applicable): selinux-policy-targeted-3.7.19-44.fc13.noarch How reproducible: Explained above. Should be reproducible with any other webmail software too. Steps to Reproduce: 1. Install software above, receive mail that you want to flag as spam, send it to spamassassin 2. Check /var/log/messages Actual results/solution by dgrift @ #fedora-selinux: First of all, upgraded to: selinux-policy-targeted-3.7.19-47.fc13.noarch Then restorecon: restorecon -R -v /var/lib/spamassassin That alone didn't solve the problem, we had to make a new module: mkdir ~/myspamc; cd ~/myspamc; echo "policy_module(myspamc, 1.0.0)" > myspamc.te; echo "gen_require(\`" >> myspamc.te; echo "type httpd_t;" >> myspamc.te; echo "')" >> myspamc.te; echo "spamassassin_domtrans_client(httpd_t)" >> myspamc.te; make -f /usr/share/selinux/devel/Makefile myspamc.pp sudo semodule -i myspamc.pp After that it was working as intended, no more AVC denials.
Also, forgot to mention that this prevented any mail from being delivered to my inbox. /var/log/maillog showed that the mail was delivered to postfix queue, but when postfix fed it to procmail, I lost trace of it (because of the same AVC denial).
Is there a specific cgi script that apache runs in order to start spamassassin?
horde is a php webapp that runs /usr/bin/spamassassiin directly i believe.
I guess then, should this be allowed under a boolean? Is httpd_can_sendmail required? If yes should this be under that boolean or do we need httpd_can_check_spam.
I do not know if Roope Karhu has the the httpd_can_sendmail boolean enabled, and so i am not sure if this is required. A boolean seems like a good idea however i am not sure whether that is even possible since spamc local policy has optional policy, and AFAIK you cannot have optional policy in conditionals?
Mind you that spamc_t can send mail.
I guess: optional_policy(` tunable_policy(`httpd_can_sendmail && httpd_can_check_spam',` spamassassin_domtrans_client(httpd_t) ') ') would make sense. My gut feeling tells me that httpd_can_sendmail is required. Since Horde is a mail client php webapp. But .. i am not sure. p.s. never mind my previous comment about optionals and conditionals because it does not apply here.
Here: $ getsebool httpd_can_sendmail httpd_can_sendmail --> on Remember that I've never had problems with SELinux before this, so I've never studied it or it's functionalities more than this. I'm mostly running with default values.
Miroslav, lets go with Dominick's suggestion.
Fixed in selinux-policy-3.7.19-50.fc13
selinux-policy-3.7.19-51.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/selinux-policy-3.7.19-51.fc13
selinux-policy-3.7.19-51.fc13 has been pushed to the Fedora 13 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 selinux-policy'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/selinux-policy-3.7.19-51.fc13
selinux-policy-3.7.19-51.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.