Bug 244255 - selinux denials of procmail (procmail_t and postfix_local_t) reading eventpoll:[NNNNN]
Summary: selinux denials of procmail (procmail_t and postfix_local_t) reading eventpol...
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: 7
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2007-06-14 18:34 UTC by David Baron
Modified: 2007-11-30 22:12 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2007-08-22 14:08:52 UTC

Attachments (Terms of Use)

Description David Baron 2007-06-14 18:34:11 UTC
Description of problem:  I'm seeing selinux denials of the following form in F7:

avc: denied { read } for comm="procmail" dev=eventpollfs egid=500 euid=500
exe="/usr/bin/procmail" exit=0 fsgid=500 fsuid=500 gid=500 items=0
name="[26707]" path="eventpoll:[26707]" pid=3831
scontext=system_u:system_r:procmail_t:s0 sgid=500
subj=system_u:system_r:procmail_t:s0 suid=500 tclass=file
tcontext=system_u:system_r:postfix_local_t:s0 tty=(none) uid=500 

This is a regression relative to FC6, although maybe only because the selinux
boolean postfix_disable_trans no longer seems to exist.

Version-Release number of selected component (if applicable):

How reproducible: Every time I receive email.

Steps to Reproduce:
1. Set up a .forward file that calls a shell script that calls procmail (my
shell script also calls clamscan and spamd, but that doesn't seem relevant), i.e.:
  |"/bin/bash ~/bin/forward-normal.sh"
2. use postfix as an MDA
3. run fetchmail
Actual results: SELinux denials.

(I know when I upgraded to F7, the selinux denials caused mail delivery to fail,
so I switched to permissive mode.  There seem to be fewer SELinux denials now
(and following a full filesystem relabel), so I'm not sure if these are the ones
that were causing delivery to fail, or if those have gone away.  But they still
probably shouldn't happen.)

Expected results:  No SELinux denials.

Comment 1 Daniel Walsh 2007-06-14 20:32:07 UTC
Could you put your machine into enforcing state and see if these avc messages
still show up.  Also see if it is blocking mail delivery.  My fix will differ
depending on the output.

Comment 2 David Baron 2007-06-14 21:54:47 UTC
In enforcing mode, the messages still show up, and they do prevent mail delivery.

Comment 3 Daniel Walsh 2007-06-15 13:05:34 UTC
Ok added policy in selinux-policy-targeted-2.6.4-16.fc7

You can add this rule yourself to make sure it works by executing

# grep procmail /var/log/audit/audit.log | audit2allow -M myprocmail
# semodule -i myprocmail.pp

Comment 4 David Baron 2007-06-19 18:40:09 UTC
Doesn't seem to be fixed in
assuming that appropriate things are reloaded following an RPM upgrade.

For what it's worth, I also see a very similar denial when executing the "mailq"

avc: denied { read } for comm="procmail" dev=eventpollfs egid=500 euid=500
exe="/usr/bin/procmail" exit=0 fsgid=500 fsuid=500 gid=500 items=0 name="[9189]"
path="eventpoll:[9189]" pid=3548 scontext=system_u:system_r:procmail_t:s0
sgid=500 subj=system_u:system_r:procmail_t:s0 suid=500 tclass=file
tcontext=system_u:system_r:postfix_master_t:s0 tty=(none) uid=500

(And the other spamassassin and clamscan-related denials are still around; I'd
just managed to make them disappear from the UI of setroubleshoot.  Should I be
filing those as bugs, or just adding rules myself as per comment 3?)

Comment 5 Daniel Walsh 2007-06-19 19:10:18 UTC
You can add the rules your self, but please report them as bugs.

Comment 6 Mark Knoop 2007-07-24 15:51:52 UTC
I'm seeing this too with selinux-policy-targeted-2.6.4-28.fc7. Fairly standard
setup using a ~/.forward to direct mail through procmail. It doesn't seem right
to be allowing postfix/procmail rw access to unlabeled files, as audit2allow
suggests. Is there a better way?

# egrep 'postfix|procmail' /var/log/audit/audit.log | audit2allow 
#============= postfix_cleanup_t ==============
allow postfix_cleanup_t unlabeled_t:file { read write };
#============= postfix_local_t ==============
allow postfix_local_t unlabeled_t:file { read write };
#============= postfix_pickup_t ==============
allow postfix_pickup_t unlabeled_t:file { read write };
#============= postfix_qmgr_t ==============
allow postfix_qmgr_t unlabeled_t:file { read write };
#============= postfix_showq_t ==============
allow postfix_showq_t unlabeled_t:file { read write };
#============= postfix_smtp_t ==============
allow postfix_smtp_t unlabeled_t:file { read write };
#============= postfix_smtpd_t ==============
allow postfix_smtpd_t unlabeled_t:file { read write };
#============= procmail_t ==============
allow procmail_t unlabeled_t:file { read write };

Comment 7 Daniel Walsh 2007-07-26 17:06:21 UTC
Yes a new file system anon_inodfs has been added to the kernel and selinux
policy did not know about it.  selinux-policy-2.6.4-29 should fix this problem.

Comment 8 Daniel Walsh 2007-08-22 14:08:52 UTC
Closing as fixes are in the current release

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