Bug 212217 - procmail triggers selinux warnings
procmail triggers selinux warnings
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2006-10-25 14:10 EDT by Pawel Salek
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-11-17 13:55:04 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Pawel Salek 2006-10-25 14:10:49 EDT
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):

How reproducible:
It is probably adding
to your .procmailrc that triggers that. Isn't the procmail policy too restrictive?
Comment 1 Daniel Walsh 2006-10-25 15:49:56 EDT
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 03:17:25 EDT
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 09:41:32 EDT
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 10:49:05 EDT
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 10:58:25 EDT
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 11:17:21 EDT
Yes, using /var/log/messages works just fine (apart from generating the same
confusing but apparently harmless error message), thanks!

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