SELinux is preventing /usr/bin/python2.7 from using the signal access on a process. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that python2.7 should be allowed signal access on processes labeled postfix_postdrop_t by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep fail2ban-server /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:fail2ban_t:s0 Target Context system_u:system_r:postfix_postdrop_t:s0 Target Objects Unknown [ process ] Source fail2ban-server Source Path /usr/bin/python2.7 Port <Unknown> Host server.interlinx.bc.ca Source RPM Packages python-2.7.5-34.el7.x86_64 Target RPM Packages Policy RPM selinux-policy-3.13.1-60.el7_2.7.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name server.interlinx.bc.ca Platform Linux server.interlinx.bc.ca 3.10.0-327.18.2.el7.x86_64 #1 SMP Thu May 12 11:03:55 UTC 2016 x86_64 x86_64 Alert Count 1 First Seen 2016-06-27 23:23:49 EDT Last Seen 2016-06-27 23:23:49 EDT Local ID b1eecb90-3c8b-4024-9334-024e301c3e3b Raw Audit Messages type=AVC msg=audit(1467084229.138:32241): avc: denied { signal } for pid=14508 comm="fail2ban-server" scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:system_r:postfix_postdrop_t:s0 tclass=process type=AVC msg=audit(1467084229.138:32241): avc: denied { signal } for pid=14508 comm="fail2ban-server" scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:system_r:system_mail_t:s0 tclass=process type=SYSCALL msg=audit(1467084229.138:32241): arch=x86_64 syscall=kill success=yes exit=0 a0=ffffb145 a1=f a2=0 a3=0 items=0 ppid=1 pid=14508 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=fail2ban-server exe=/usr/bin/python2.7 subj=system_u:system_r:fail2ban_t:s0 key=(null) Hash: fail2ban-server,fail2ban_t,postfix_postdrop_t,process,signal
Looks like this is a duplicate of 1377115. I wonder why abrt didn't find that. In any case this or the other should be closed as DUPLICATE.
*** Bug 1377115 has been marked as a duplicate of this bug. ***
This bugzilla was triaged as "WONTFIX" by the SELinux team, due to third-party software component which can be fixed by component maintainer. To take advantage of Mandatory Access Control mechanism provided by SELinux, you (component maintainer) can ship custom SELinux policy as a subpackage of the affected component. As a starting point you can use policy provided by selinux-policy package. For more details about the custom product policy, please follow the https://fedoraproject.org/wiki/SELinux/IndependentPolicy guideline.
I'd like to know what fail2ban is trying to do here. Near as I can tell/guess this would be because a command executed by fail2ban timed out. In this case fail2ban.log should show something like: <command> -- timed out after 60 seconds <command> -- unable to kill PID <NN> Do you see these messages?
Yes, I see such messages: 2017-08-01 08:36:34,002 fail2ban.action [3111]: ERROR printf %b "Subject: [Fail2Ban] XXX: banned x.x.x.x Date: `date -u +"%a, %d %h %Y %T +0000"` From: Fail2Ban <root> To: root\n Hi,\n The IP x.x.x.x has just been banned by Fail2Ban after 3 attempts against XXX.\n\n Lines containing IP:x.x.x.x. in /var/log/messages\n `/bin/grep '\<x.x.x.x.\>' /var/log/messages`\n\n Here are more information about x.x.x.x:\n `/usr/bin/whois x.x.x.x 2>&1`\n\n Regards,\n Fail2Ban" | /usr/sbin/sendmail -f root root -- unable to kill PID 11154 I don't know of any reason why that command should take anywhere near 60 seconds to execute though: # time bash -c 'echo test | /usr/sbin/sendmail -f root root' real 0m0.112s user 0m0.013s sys 0m0.027s
And the e-mail that that error message said timed out after 60 seconds was actually successfully delivered and took only 17 seconds (16 seconds in spam checking) from first contact to postfix to being removed from the delivery queue after being delivered.
Well, for one thing - you certainly don't want to be sending mail from 'root'. Be sure to set "sender" as desired. But this doesn't seem likely the cause. Does the email contain the output of the grep and whois commands?
(In reply to Orion Poplawski from comment #9) > Well, for one thing - you certainly don't want to be sending mail from > 'root'. Of course not. Clearly that was simply a change of the real address when being pasted to a public forum like this BZ so that the actual address would not be scraped and spammed. > But this doesn't > seem likely the cause. No, not at all. > Does the email contain the output of the grep and > whois commands? Yes. But even in the largest e-mail matching the error from the fail2ban.log, the e-mail was only 23KB big.
I have recently taken maintainership of the fail2ban package and created a COPR for EPEL 7 & 8 of the latest version. I could use some feedback. https://copr.fedorainfracloud.org/coprs/hobbes1069/fail2ban/ Is this problem still present in 0.11.1?
It's been a month without response so I'm closing this bug. Please reopen if needed.