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): selinux-policy-2.6.4-13.fc7 selinux-policy-targeted-2.6.4-13.fc7 postfix-2.4.3-2.fc7 procmail-3.22-19.fc7 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.
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.
In enforcing mode, the messages still show up, and they do prevent mail delivery.
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
Doesn't seem to be fixed in selinux-policy-targeted-2.6.4-17.fc7 selinux-policy-2.6.4-17.fc7 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" command: 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?)
You can add the rules your self, but please report them as bugs.
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 };
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.
Closing as fixes are in the current release