Bug 1132514

Summary: SELinux policy denies reading from journal
Product: [Fedora] Fedora EPEL Reporter: Matrix <matic>
Component: fail2banAssignee: Orion Poplawski <orion>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: epel7CC: jbnance, orion, peter.niederlag, vonsch
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-04-07 22:06:26 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: 1133248    
Bug Blocks:    

Description Matrix 2014-08-21 13:38:12 UTC
Description of problem:
In default configuration fail2ban (f2b) reads from systemd's journal but it cannot because SELinux is preventing it, yet there are not errors reported in f2b's log.

Version-Release number of selected component (if applicable):
fail2ban-0.9-9.el7.noarch

How reproducible:
Always

Steps to Reproduce:
1. Install fail2ban and enable "sshd" jail.
2. $ ausearch -i -m avc


Actual results:
1. f2b is unable to read/follow journal and doesn't know about failed logins. Product is unable to do it's job.
2. Causes admin frustration and anger because of silent failure.

Expected results:
Doesn't work. And f2b doesn't report any errors even though there are.

Additional info:

Comment 1 Orion Poplawski 2014-08-23 19:04:36 UTC
I've filed a bug to get the policy fixed.  As for the lack of error messages, I'm wondering if that is a systemd-python issue.  Poking around.

Comment 2 peterN 2014-09-19 11:06:54 UTC
I can confirm this problem. Is there any recommended workaround until the fix for #1133248 is released?

Comment 3 Orion Poplawski 2014-09-19 15:15:59 UTC
Just the usual method of using audit2allow to create a custom policy module.

Comment 4 Jason Bradley Nance 2014-11-25 02:07:26 UTC
Here are the missing policies (at least for fail2ban on RHEL 7):



module myfail2ban 1.0;

require {
        type fail2ban_client_exec_t;
        type logrotate_t;
        class file { read execute open execute_no_trans };
}

#============= logrotate_t ==============
allow logrotate_t fail2ban_client_exec_t:file { read execute open execute_no_trans };

require {
        type syslogd_var_run_t;
        type fail2ban_t;
        class dir read;
}

#============= fail2ban_t ==============
allow fail2ban_t syslogd_var_run_t:dir read;

require {
        type syslogd_var_run_t;
        type fail2ban_t;
        class file { read open getattr };
}

#============= fail2ban_t ==============
allow fail2ban_t syslogd_var_run_t:file { read open getattr };



You can copy / paste the above into myfail2ban.te, then run:

$ sudo checkmodule -M -m -o myfail2ban.mod myfail2ban.te
$ sudo semodule_package -o myfail2ban.pp -m myfail2ban.mod
$ sudo semodule -i myfail2ban.pp

The reason for the "my" prefix is to not collide with the fail2ban policy provided by selinux-policy-targeted.  Once upstream fixes the policy you can delete your "my" module.

Comment 5 Orion Poplawski 2015-04-07 22:06:26 UTC
I think this is fixed by the selinux-policy changes.