This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 486187 - RHEL-5.3 selinux-policy broke spamassassin
RHEL-5.3 selinux-policy broke spamassassin
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy (Show other bugs)
5.3
x86_64 Linux
low Severity medium
: rc
: ---
Assigned To: Daniel Walsh
BaseOS QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-18 14:37 EST by Greg
Modified: 2012-10-15 04:40 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-02 03:59:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Greg 2009-02-18 14:37:58 EST
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:
Comment 1 Cale Fairchild 2009-02-22 21:10:28 EST
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.
Comment 2 Daniel Walsh 2009-02-23 11:36:49 EST
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
Comment 3 Cale Fairchild 2009-02-23 11:59:16 EST
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.
Comment 4 Mike A. Harris 2009-04-03 10:35:07 EDT
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?
Comment 6 Warren Togami 2009-04-04 10:20:26 EDT
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.
Comment 7 Mike A. Harris 2009-04-04 17:44:23 EDT
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.
Comment 8 Daniel Walsh 2009-04-06 08:28:12 EDT
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
Comment 9 Warren Togami 2009-04-06 10:14:29 EDT
Oh, yeah it is likely a leaked file descriptor.
Comment 13 David Houlder 2009-05-11 00:12:39 EDT
(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.
Comment 14 Daniel Walsh 2009-05-11 08:21:38 EDT
Can you try the policy on http://people.redhat.com/dwalsh/SELinux/RHEL5

This is the RHEL5.4 update.
Comment 16 Daniel Walsh 2009-05-12 09:26:07 EDT
Fixed in selinux-policy-2.4.6-234.el5
Preview to U4 policy is available on 
http://people.redhat.com/dwalsh/SElinux/RHEL5
Comment 18 Dave Oksner 2009-05-29 14:57:31 EDT
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).
Comment 19 Daniel Walsh 2009-06-01 12:56:29 EDT
If you chcon -t spamassassin_exec_t /usr/bin/sa-learn

Does everything work ok?
Comment 20 Dave Oksner 2009-06-01 14:01:45 EDT
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?
Comment 21 Daniel Walsh 2009-06-02 08:34:53 EDT
Yes I will change the default label.   In the next policy update for RHEL5.4
Comment 23 Chris Ward 2009-07-03 14:25:02 EDT
~~ 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.
Comment 26 Mike A. Harris 2009-08-06 19:45:27 EDT
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.
Comment 28 errata-xmlrpc 2009-09-02 03:59:48 EDT
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

Note You need to log in before you can comment on or make changes to this bug.