Description of problem: After upgrading to spamassassin-3.2.5-1.el5 using up2date, spamassassin stopped filtering messages. Mail logs revealed the following problem: procmail: Executing "/usr/bin/spamc" /bin/sh: /usr/bin/spamc: Permission denied procmail: Program failure (126) of "/usr/bin/spamc" This appears to be a problem with SELinux. When I disable SELinux or set enforcement mode to permissive, the problem goes away. However, when put SELinux back in enforcement mode and set the Booleans to allow SA daemon network access and to disable SELinux protection for spamd daemon, the problem returns. I would prefer not to have SELinux in permissive mode, but don't know how to get it to work with spamassassin in enforcement mode. Perhaps this is a problem with sendmail/procmail? Version-Release number of selected component (if applicable): How reproducible: Always reproducible. Steps to Reproduce: 1. Set SELinux to enforcement mode. 2. 3. Actual results: Procmail is denied permission to invoke spamc. Expected results: Procmail should have no problem invoking spamc. Additional info:
I too have had issues since my upgrade on Friday. I run spamassassin rather than spamc from procmail, but the problem is the same. Here are the errors from the audit log. type=AVC msg=audit(1235351882.128:26319): avc: denied { read } for pid=3230 comm="sh" name="spamassassin" dev=sda1 ino=1962127 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:spamassassin_exec_t:s0 tclass=file type=AVC msg=audit(1235351927.459:26331): avc: denied { execute } for pid=3294 comm="procmail" name="spamassassin" dev=sda1 ino=1962127 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:spamassassin_exec_t:s0 tclass=file A few quick searches of getsebool -a did not reveal any configurable selinux booleans for procmail in the policies. I am using selinux-policy-targeted-2.4.6-203.el5.noarch so I am guessing that there are some new procmail rules within.
Should be fixed in selinux-policy-2.4.6-212.el5.noarch.rpm You can grab this prerelease package off of http://people.redhat.com/dwalsh/SELinux/RHEL5
Just to compare notes, here is what I came up with for a workaround selinux module definition. module myprocmail 1.0; require { type spamd_var_lib_t; type spamassassin_exec_t; type procmail_t; class file { read ioctl execute execute_no_trans getattr }; class dir search; } #============= procmail_t ============== allow procmail_t spamassassin_exec_t:file { read ioctl execute execute_no_trans getattr }; allow procmail_t spamd_var_lib_t:dir search; I also have found a couple more selinux problems that I will open tickets for today, in case they can get inserted to this coming release. Thanks.
I've got selinux-policy-2.4.6-217.el5 selinux-policy-targeted-2.4.6-217.el5 both installed, and I've rebooted however procmail is still unable to execute /usr/bin/spamc SummarySELinux is preventing procmail (procmail_t) "execute" to ./spamc (spamc_exec_t). Detailed DescriptionSELinux denied access requested by procmail. It is not expected that this access is required by procmail 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 AccessSometimes labeling problems can cause SELinux denials. You could try to restore the default system file context for ./spamc, restorecon -v './spamc' If this does not work, there is currently no automatic way to allow this access. Instead, you can generate a local policy module to allow this access - see FAQ Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report against this package. Additional InformationSource Context: system_u:system_r:procmail_tTarget Context: system_u:object_r:spamc_exec_tTarget Objects: ./spamc [ file ]Source: procmailSource Path: /usr/bin/procmailPort: <Unknown>Host: hammerSource RPM Packages: procmail-3.22-17.1.el5.centosTarget RPM Packages: Policy RPM: selinux-policy-2.4.6-217.el5Selinux Enabled: TruePolicy Type: targetedMLS Enabled: TrueEnforcing Mode: EnforcingPlugin Name: catchall_fileHost Name: hammerPlatform: Linux hammer 2.6.18-128.1.6.el5 #1 SMP Wed Apr 1 09:19:18 EDT 2009 i686 athlonAlert Count: 14First Seen: Fri 03 Apr 2009 09:21:39 AM EDTLast Seen: Fri 03 Apr 2009 10:32:08 AM EDTLocal ID: 61eb22fb-cdf3-41e8-98b6-d01b94555aa4Line Numbers: Raw Audit Messages :host=hammer type=AVC msg=audit(1238769128.126:40): avc: denied { execute } for pid=4063 comm="procmail" name="spamc" dev=hda1 ino=936505 scontext=system_u:system_r:procmail_t:s0 tcontext=system_u:object_r:spamc_exec_t:s0 tclass=file host=hammer type=SYSCALL msg=audit(1238769128.126:40): arch=40000003 syscall=11 success=no exit=-13 a0=992ed90 a1=992e020 a2=9930770 a3=0 items=0 ppid=4062 pid=4063 auid=4294967295 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=12 fsgid=500 tty=(none) ses=4294967295 comm="procmail" exe="/usr/bin/procmail" subj=system_u:system_r:procmail_t:s0 key=(null) procmail: Executing "/usr/bin/spamc" /bin/sh: /usr/bin/spamc: Permission denied procmail: Program failure (126) of "/usr/bin/spamc" Any other suggestions?
The following packages resolve this issue for me: http://people.redhat.com/dwalsh/SELinux/RHEL5/noarch/selinux-policy-2.4.6-220.el5.noarch.rpm http://people.redhat.com/dwalsh/SELinux/RHEL5/noarch/selinux-policy-targeted-2.4.6-220.el5.noarch.rpm Thanks Dan!
type=AVC msg=audit(1238795078.042:796): avc: denied { write } for pid=7570 comm="spamc" path="pipe:[47206]" dev=pipefs ino=47206 scontext=root:system_r:spamc_t:s0 tcontext=root:system_r:postfix_local_t:s0 tclass=fifo_file spamassassin invoked by procmail via postfix is still failing for me.
While the new packages fix the spamc problem for me, they have introduced a new problem. I'm getting new AVC denials: Summary: SELinux is preventing the spamc from using potentially mislabeled files (/home/mharris/log/procmail.log). Detailed Description: SELinux has denied spamc access to potentially mislabeled file(s) (/home/mharris/log/procmail.log). This means that SELinux will not allow spamc to use these files. It is common for users to edit files in their home directory or tmp directories and then move (mv) them to system directories. The problem is that the files end up with the wrong file context which confined applications are not allowed to access. Allowing Access: If you want spamc to access this files, you need to relabel them using restorecon -v '/home/mharris/log/procmail.log'. You might want to relabel the entire directory using restorecon -R -v '/home/mharris/log'. Additional Information: Source Context system_u:system_r:spamc_t Target Context system_u:object_r:user_home_t Target Objects /home/mharris/log/procmail.log [ file ] Source spamc Source Path /usr/bin/spamc Port <Unknown> Host hammer Source RPM Packages spamassassin-3.2.5-1.el5 Target RPM Packages Policy RPM selinux-policy-2.4.6-220.el5 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name home_tmp_bad_labels Host Name hammer Platform Linux hammer 2.6.18-128.1.6.el5 #1 SMP Wed Apr 1 09:19:18 EDT 2009 i686 athlon Alert Count 243 First Seen Fri 03 Apr 2009 01:27:09 PM EDT Last Seen Sat 04 Apr 2009 05:23:20 PM EDT Local ID 41214bfd-bc0b-4960-9976-e2518bd88c5c Line Numbers Raw Audit Messages host=hammer type=AVC msg=audit(1238880200.51:654): avc: denied { append } for pid=25358 comm="spamc" path="/home/mharris/log/procmail.log" dev=hda2 ino=1756195 scontext=system_u:system_r:spamc_t:s0 tcontext=system_u:object_r:user_home_t:s0 tclass=file host=hammer type=SYSCALL msg=audit(1238880200.51:654): arch=40000003 syscall=11 success=yes exit=0 a0=93d9d90 a1=93d9020 a2=93db7a0 a3=0 items=0 ppid=25357 pid=25358 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) Basically, I use fetchmail+procmail+spamc+spambayes from my 'mharris' user account, using a personal .fetchmailrc and .procmailrc and my .procmailrc includes the line: LOGFILE="${HOME}/log/procmail.log" Procmail has always been able to write to the log ok, and it still writes to the log, but when it calls spamc now, while spamc does work properly, the denial occurs preventing spamc from writing to the procmail log. spambayes' sb_filter.py script doesn't encounter this problem (if that's of any assistance). Hope this helps.
Warren is it failing or just generating an AVC? This looks like a leaked file descriptor from postfix or a redirection of stdout, which should not cause spamc to fail. Both will be allowed in selinux-policy-2.4.6-221.el5
Oh, yeah it is likely a leaked file descriptor.
(In reply to comment #3) I had to amend this workaround a bit to make it work for spamc too. > Just to compare notes, here is what I came up with for a workaround selinux > module definition. > > module myprocmail 1.0; > > require { > type spamd_var_lib_t; > type spamassassin_exec_t; type spamc_exec_t; > type procmail_t; > class file { read ioctl execute execute_no_trans getattr }; > class dir search; > } > > #============= procmail_t ============== > allow procmail_t spamassassin_exec_t:file { read ioctl execute execute_no_trans allow procmail_t spamc_exec_t:file { read ioctl execute execute_no_trans getattr }; > getattr }; > allow procmail_t spamd_var_lib_t:dir search; > > I also have found a couple more selinux problems that I will open tickets for > today, in case they can get inserted to this coming release. > > Thanks.
Can you try the policy on http://people.redhat.com/dwalsh/SELinux/RHEL5 This is the RHEL5.4 update.
Fixed in selinux-policy-2.4.6-234.el5 Preview to U4 policy is available on http://people.redhat.com/dwalsh/SElinux/RHEL5
Just installed version 235 and it got rid of several spamassassin problems I was seeing. However, there are still problems with running sa-learn. I believe this only happens when something qualifies to autolearn. This does not appear to happen when I run sa-learn manually (from within a script). If I get any more undetected spam today, the script will get run via cron tonight and I can comment on that, too. The main problems appear to be sa-learn (spamc_t) getting access to the $HOME/.spamassassin directory and its contents (spamassassin_home_t) and /var/lib/spamassassin (spamd_var_lib_t).
If you chcon -t spamassassin_exec_t /usr/bin/sa-learn Does everything work ok?
Thanks--that does appear to stop the alerts (and I should be able to go back to enforcing). I see that this is not the default context for this file. Do you consider this a bug in the policy or am I using it differently than most people and/or not how it was intended?
Yes I will change the default label. In the next policy update for RHEL5.4
~~ Attention - RHEL 5.4 Beta Released! ~~ RHEL 5.4 Beta has been released! There should be a fix present in the Beta release that addresses this particular request. Please test and report back results here, at your earliest convenience. RHEL 5.4 General Availability release is just around the corner! If you encounter any issues while testing Beta, please describe the issues you have encountered and set the bug into NEED_INFO. If you encounter new issues, please clone this bug to open a new issue and request it be reviewed for inclusion in RHEL 5.4 or a later update, if it is not of urgent severity. Please do not flip the bug status to VERIFIED. Only post your verification results, and if available, update Verified field with the appropriate value. Questions can be posted to this bug or your customer or partner representative.
The problem with spamc that I was encountering seems to be resolved with the 250 build. It's been well over a week since I've seen a denial for spamc.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-1242.html