Bug 212217

Summary: procmail triggers selinux warnings
Product: [Fedora] Fedora Reporter: Pawel Salek <pawsa>
Component: selinux-policyAssignee: Daniel Walsh <dwalsh>
Status: CLOSED NOTABUG QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 6CC: dwalsh
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-11-17 18:55:04 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Pawel Salek 2006-10-25 18:10:49 UTC
Description of problem:
audit(1161761941.960:8): avc:  denied  { search } for  pid=4041 comm="procmail"
name="tmp" dev=dm-0 ino=1865953 scontext=system_u:system_r:procmail_t:s0
tcontext=system_u:object_r:tmp_t:s0 tclass=dir


Version-Release number of selected component (if applicable):
selinux-policy-2.3.18-10
selinux-policy-targeted-2.3.18-10

How reproducible:
It is probably adding
LOGFILE=/tmp/pm.log
to your .procmailrc that triggers that. Isn't the procmail policy too restrictive?

Comment 1 Daniel Walsh 2006-10-25 19:49:56 UTC
If you want to add this priv, you can with 


setenforce 0
run procmail in permissive mode
audit2allow -R -m local -i /var/log/audit/audit.log
semodule -i local.pp
setenforce 1

Comment 2 Pawel Salek 2006-10-26 07:17:25 UTC
I take exception to the comment above:
1. the fact that procmail is not allowed to write to /tmp is not documented.
2. /usr/sbin/semodule -i local.pp
/usr/sbin/semodule:  Could not read file 'local.pp':
Perhaps because audit2allow wrote the rules on the screen.

Comment 3 Daniel Walsh 2006-10-26 13:41:32 UTC
Sorry should have been
audit2allow -R -M local -i /var/log/audit/audit.log

You may take exception to the fact, but having allowing a system daemon to write
to /tmp is not a great idea.  Since it can theoretically attack userspace from
there.  With FC5/FC6 and RHEL5 you have the ability to customise SELinux policy
to enforce policy any way you want.  But we can not write policy to allow
applications to run in all possible configurations, because they will quickly
desolve to providing no protection.  

Comment 4 Pawel Salek 2006-10-26 14:49:05 UTC
Ad  1. I understand your concern about system daemons writing to /tmp - but this
is *not* documented. Many recipes for using procmail (see for example
http://pm-doc.sourceforge.net/pm-tips.html) create temporary files in /tmp
directory and they will be silently broken by such procmail rules. Think of all
the users that test their recipes by manual delivery (and everything works) and
silently breaking when procmail is executed by sendmail. And the difference
dissapearing when SElinux is disabled. It seems this (ie. disabling SELinux) is
what this setting is trying to achieve.

Ad 2. audit2allow still does not work as specified: There is no
/var/log/audit/audit.log being created in default FC6 configuration, or any file
with similar name. 
Running "audit2allow -R -M local -d" generates worrisome output:
Generating type enforcment file: local.te
Compiling policy
checkmodule -M -m -o local.mod local.te
/usr/bin/audit2allow: (unknown source)::ERROR 'syntax error' at token
'policy_module' on line 1:


checkmodule:  error(s) encountered while parsing configuration
checkmodule:  loading policy configuration from local.te
but it seems the local.te file is applied to the configuration. Will this be
preserved after reboot? I guess I can find it out on my own.


Comment 5 Daniel Walsh 2006-10-26 14:58:25 UTC
Yes it will survive a reboot or a upgrade.

You might want to install setroubleshoot

Which will inform you when you have an selinux problem, and try to translate it
to something an admin can do to remedy the denial

yum -y install setroubleshoot

I have not seen that error with audit2allow

audit2allow -M -local -i /var/log/messages 
should work?

Comment 6 Pawel Salek 2006-10-26 15:17:21 UTC
Yes, using /var/log/messages works just fine (apart from generating the same
confusing but apparently harmless error message), thanks!