Bug 1124539 - Fail2ban needs to read audit log files
Summary: Fail2ban needs to read audit log files
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted
Version: 20
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Ben Levenson
Depends On:
TreeView+ depends on / blocked
Reported: 2014-07-29 17:57 UTC by Göran Uddeborg
Modified: 2014-08-30 03:54 UTC (History)
2 users (show)

Fixed In Version: selinux-policy-3.12.1-182.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-08-30 03:54:58 UTC

Attachments (Terms of Use)

Description Göran Uddeborg 2014-07-29 17:57:51 UTC
Description of problem:
When activating the selinux-ssh jail in fail2ban, the entire fail2ban service fails to start up.

Version-Release number of selected component (if applicable):

How reproducible:
Every time.

Steps to Reproduce:
1. Enable the selinux-ssh jail in a jail.local file in /etc/fail2ban
2. Start the fail2ban service

Actual results:
The service fails to start.

Expected results:
The fail2ban service should run and check login attempts in the audit logs.

Additional info:
If I disable dontaudit rules, I get AVC:s about fail2ban_client_t not being allowed to search auditd_log_t directories.  When searching bugzilla, I found bug 1119002 about this message.  That bugzilla had been resolved by dontaudit:ing these messages.

But the access is actually necessary.  Fail2ban is looking in the audit logs for traces of attacks.  So it needs to be allowed, not ignored.  Experimenting with a local "fail2banfix" module a bit, I found out it also needs some additional permissions in order to read the log files.  (Not surprising.)  I ended up adding the line


to my module.

That makes the fail2ban service start.  But now I get AVC:s about fail2ban_t being disallowed the same access.  See an example below.  If I understand things correctly, a fail2ban_client_t process is run during startup to look for attacks before the service is started, while fail2ban_t is the server doing the continuous monitoring for new attacks.  So I also added this line


to my module.  And now, finally, I'm able to trigger the selinux-ssh jail!

I believe something like these rules should be added to the standard policy.

type=SYSCALL msg=audit(1406652876.657:15133): arch=c000003e syscall=2 success=no exit=-13 a0=10145b0 a1=0 a2=1b6 a3=7fd9bc3255d0 items=0 ppid=1 pid=14113 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)
type=AVC msg=audit(1406652876.657:15133): avc:  denied  { search } for  pid=14113 comm="fail2ban-server" name="audit" dev="dm-0" ino=5112304 scontext=system_u:system_r:fail2ban_t:s0 tcontext=system_u:object_r:auditd_log_t:s0 tclass=dir

Comment 1 Daniel Walsh 2014-08-06 21:55:55 UTC
26bcf7da6ad03cb45d6a73c5736757dfd9f46493 fixes this in git.

I agree it should be allowed.

Comment 2 Lukas Vrabec 2014-08-27 12:47:20 UTC
commit 066eb2b7856c09b138568ac8b3f884d48154c6c0
Author: Dan Walsh <dwalsh@redhat.com>
Date:   Wed Aug 6 17:55:06 2014 -0400

    Allow fail2ban to read audit logs


Comment 3 Fedora Update System 2014-08-27 14:52:58 UTC
selinux-policy-3.12.1-182.fc20 has been submitted as an update for Fedora 20.

Comment 4 Fedora Update System 2014-08-28 15:30:49 UTC
Package selinux-policy-3.12.1-182.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing selinux-policy-3.12.1-182.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).

Comment 5 Fedora Update System 2014-08-30 03:54:58 UTC
selinux-policy-3.12.1-182.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.