Bug 1435449

Summary: fail2ban SElinux blockage - easyfix w included TE rule
Product: [Fedora] Fedora EPEL Reporter: R P Herrold <herrold>
Component: fail2banAssignee: Richard Shaw <hobbes1069>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: el6CC: athmanem, brian, davama, extras-qa, hobbes1069, lvrabec, mmalik, orion, plautrba, pvrabec, ssekidde, vonsch
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1350894 Environment:
Last Closed: 2020-04-22 20:53:03 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1350894    
Bug Blocks: 1393066    
Attachments:
Description Flags
f2b and MM
none
TE rule being tested on a non-MM host, and so not producing the MailMan noise none

Description R P Herrold 2017-03-23 20:26:58 UTC 
+++ 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]#
Comment 1 R P Herrold 2017-07-13 18:06:48 UTC 
ping -- this remains NEW< and seemingly untouched -- what may I do to advance this?
Comment 2 R P Herrold 2017-07-28 14:23:56 UTC 
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)
Comment 3 R P Herrold 2017-07-28 14:25:07 UTC 
Created attachment 1305976 [details]
f2b and MM
Comment 4 Orion Poplawski 2017-08-03 03:58:09 UTC 
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.
Comment 5 R P Herrold 2017-08-23 13:41:19 UTC 
concur as to Mailman .. the unit which this ruleset was derived on had other issues, and I missed puilling that out manually
Comment 6 R P Herrold 2017-10-25 17:25:31 UTC 
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
Comment 7 R P Herrold 2017-10-25 17:30:04 UTC 
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
Comment 8 R P Herrold 2017-11-03 15:32:02 UTC 
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
Comment 9 R P Herrold 2017-11-14 17:32:49 UTC 
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]#
Comment 10 R P Herrold 2018-02-19 19:44:25 UTC 
This revised ruleset seems to be complete as to my use case-- how to get it applied?
Comment 11 Richard Shaw 2020-03-22 17:06:03 UTC 
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/
Comment 12 Richard Shaw 2020-04-22 20:53:03 UTC 
No response in one month closing.