+++ This bug was initially created as a clone of Bug #1350894 +++ SELinux is preventing /usr/bin/python2.7 from using the signal access on a process. I have cloned this bug as the SElinux team has been handing such bugs back to maintainers this weel ============= I see a similar bug in EPEL 6 p[root@router jail.d]# service fail2ban restartStopping fail2ban: [ OK ] Starting fail2ban: ERROR NOK: (13, 'Permission denied') [ OK ] [root@router jail.d]# fixed by a new SElinux rule p[root@router jail.d]# service fail2ban restartStopping fail2ban: [ OK ] Starting fail2ban: [ OK ] [root@router jail.d]# rpm -q fail2ban fail2ban-0.9.6-1.el6.1.noarch [root@router jail.d]# [root@router jail.d]# cat local.te module local 1.0; require { type auditd_log_t; type fail2ban_t; class dir search; class file { read getattr open }; } #============= fail2ban_t ============== allow fail2ban_t auditd_log_t:dir search; allow fail2ban_t auditd_log_t:file getattr; allow fail2ban_t auditd_log_t:file { read open }; [root@router jail.d]#
ping -- this remains NEW< and seemingly untouched -- what may I do to advance this?
This continues -- in an interaction with MailMan, and a later fail2ban in the 0.9 series, rolled from a github pull, I ended up with this (attached)
Created attachment 1305976 [details] f2b and MM
There seems to be some different things going on here than mentioned in the other bug. Looks like the auditd_log_t stuff is needed for the selinux-ssh jail - and these rules do appear to be present in EL7 policy, but looks like this policy needs to get backported to EL6. I'll see what I can do. I don't see what place changing the mailman_mail_t permissions has in the fail2ban policy - this doesn't seem related at all to fail2ban.
concur as to Mailman .. the unit which this ruleset was derived on had other issues, and I missed puilling that out manually
sadly, the 'turn off SELinux' folks are in front on search engine hits on this https://support.plesk.com/hc/en-us/articles/213395569-Fail2ban-jail-activation-error-ERROR-NOK-13-Permission-denied- I updated my ruleset, and replace the attachment it needs malefactors to test it of course, to trigger the SELinux rules, so we shall see
Created attachment 1343323 [details] TE rule being tested on a non-MM host, and so not producing the MailMan noise in testing -- local notes on the change at: /home/herrold/fail2ban/README-selinux-6 to preserve hostname privacy
I have had the tester running hourly for a week, looking for any SElinux noise, and none has appeared Please consider this a Pull Request, for the revised patch for application
A new failure mode in EPEL 7 emerged as follows (on a different unit than the one producing the other ruleset, and a differing set of F2B rules in effect: [root@router selinux]# cat local.te-1510680016 module local 1.0; require { type fail2ban_t; class process getpgid; } #============= fail2ban_t ============== #!!!! This avc is allowed in the current policy allow fail2ban_t self:process getpgid; [root@router selinux]# rpm -q fail2ban fail2ban-0.9.7-1.el7.noarch [root@router selinux]#
This revised ruleset seems to be complete as to my use case-- how to get it applied?
I have recently taken maintainership of the fail2ban package and created a COPR for EPEL 7 & 8 of the latest version. I don't currently plan to support EL6. Are you still seeing this in EL7? https://copr.fedorainfracloud.org/coprs/hobbes1069/fail2ban/
No response in one month closing.