Bug 522767 - SELinux problems with fail2ban
SELinux problems with fail2ban
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
:
: 483510 505926 518752 522898 523361 526485 530876 532103 539576 539577 548648 550798 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-11 07:06 EDT by Axel Thimm
Modified: 2014-12-14 17:25 EST (History)
17 users (show)

See Also:
Fixed In Version: 0.8.4-24.fc12
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 548648 (view as bug list)
Environment:
Last Closed: 2010-02-04 20:16:21 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Set socket file descriptor in AsyncServer.start to be CLOEXEC (1.19 KB, patch)
2010-01-02 21:50 EST, Jonathan Underwood
no flags Details | Diff

  None (edit)
Description Axel Thimm 2009-09-11 07:06:26 EDT
This is a merger bug for all the current fail2ban bugs that are selinux related. According to bug 508171 comment 13 fail2ban 0.8.4 might have all or most selinux issues fixed. Also many selinux reports look very similar.

Please try to reproduce the bug against the latest fail2ban 0.8.4 package soon available in updates-testing/rawhide. Thanks!

fail2ban-0.8.4-23.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/fail2ban-0.8.4-23.fc11  

fail2ban-0.8.4-23.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/fail2ban-0.8.4-23.fc10
Comment 1 Axel Thimm 2009-09-11 07:07:28 EDT
*** Bug 518752 has been marked as a duplicate of this bug. ***
Comment 2 Axel Thimm 2009-09-11 07:07:58 EDT
*** Bug 505926 has been marked as a duplicate of this bug. ***
Comment 3 Axel Thimm 2009-09-11 07:08:12 EDT
*** Bug 483510 has been marked as a duplicate of this bug. ***
Comment 4 Axel Thimm 2009-09-15 10:37:16 EDT
(In reply to bug 522898 comment #0)
> Created an attachment (id=360750) [details]
> Setroubleshootd message
> 
> Description of problem:
> Starting fail2ban from the init script procs the following avc: 
> node=narue type=AVC msg=audit(1252721615.541:505): avc: denied { create } for
> pid=28955 comm="fail2ban-server" scontext=unconfined_u:system_r:fail2ban_t:s0
> tcontext=unconfined_u:system_r:fail2ban_t:s0 tclass=unix_dgram_socket
> node=narue type=SYSCALL msg=audit(1252721615.541:505): arch=c000003e syscall=41
> success=no exit=-13 a0=1 a1=2 a2=0 a3=7fffe76d3368 items=0 ppid=1 pid=28955
> auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none)
> ses=1 comm="fail2ban-server" exe="/usr/bin/python"
> subj=unconfined_u:system_r:fail2ban_t:s0 key=(null) 
> 
> Version-Release number of selected component (if applicable):
> fail2ban-0.8.4-23.fc11.noarch
> selinux-policy-3.6.12-82.fc11.noarch
> selinux-policy-targeted-3.6.12-82.fc11.noarch
> 
> How reproducible:
> Every time
> 
> Steps to Reproduce:
> 1. /sbin/service fail2ban start
> 
> Actual results:
> fail2ban-server creates (or tries to) /var/run/fail2ban/fail2ban.sock then
> fails horribly
> 
> Expected results:
> fail2ban-server creates /var/run/fail2ban/fail2ban.sock then starts banning
> people
> 
> Additional info:
> Attached is the full setroubleshootd output.
> 
> If I start the server with `fail2ban-client start`, it works fine. I get errors
> further down the chain, but that's not part of this bug report.
> 
> `grep fail2ban /var/log/audit/audit.log|audit2allow -M fail2ban` creates the
> following .te:
> module fail2ban 1.0;
> 
> require {
>  type fail2ban_t;
>  class unix_dgram_socket create;
> }
> 
> #============= fail2ban_t ==============
> allow fail2ban_t self:unix_dgram_socket create;
> 
> However, `semodule -i fail2ban.pp` fails with:
> libsepol.print_missing_requirements: fail2ban's global requirements were not
> met: type/attribute fail2ban_t
> libsemanage.semanage_link_sandbox: Link packages failed
> semodule:  Failed!
Comment 5 Axel Thimm 2009-09-15 10:37:37 EDT
*** Bug 522898 has been marked as a duplicate of this bug. ***
Comment 6 Axel Thimm 2009-09-15 10:37:56 EDT
*** Bug 523361 has been marked as a duplicate of this bug. ***
Comment 7 Daniel Walsh 2009-09-15 11:20:33 EDT
Miroslav I think we need to add

allow fail2ban_t self:unix_dgram_socket create_socket_perms;

manage_sock_files_pattern(fail2ban_t, fail2ban_var_run_t,  fail2ban_var_run_t)
manage_files_pattern(fail2ban_t, fail2ban_var_run_t,  fail2ban_var_run_t)
files_pid_filetrans(fail2ban_t,fail2ban_var_run_t, file)

/var/run/fail2ban(/.*)?		gen_context(system_u:object_r:fail2ban_var_run_t,s0)
Comment 8 Göran Uddeborg 2009-10-23 17:17:55 EDT
I upgraded to fail2ban-0.8.4-23.fc11.noarch.  I made a local policy module to add to the default (selinux-policy-targeted-3.6.12-78.fc11.noarch) with this content:

policy_module(fail2banfix,1.2)

require {
        type fail2ban_t;
        type fail2ban_var_run_t;
        type devlog_t;
        type syslogd_t;
        all_kernel_class_perms
}

allow fail2ban_t self:unix_dgram_socket create_socket_perms;
allow fail2ban_t devlog_t:sock_file write;
allow fail2ban_t syslogd_t:unix_dgram_socket sendto;

manage_sock_files_pattern(fail2ban_t, fail2ban_var_run_t,  fail2ban_var_run_t)
manage_files_pattern(fail2ban_t, fail2ban_var_run_t,  fail2ban_var_run_t)
files_pid_filetrans(fail2ban_t,fail2ban_var_run_t, file)

Despite that, I still got the following AVC denials after restarting fail2ban.  Unless I've done something wrong here, the problems do not seem fixed.

Except for the logrotate AVC denial, it looks as leaked file descriptors to me. And as such presumably are harmless, but annoying and something that should be fixed in fail2ban eventually.
========================================
node=mimmi type=AVC msg=audit(1256093424.364:35877): avc:  denied  { write } for  pid=20772 comm="fail2ban-client" name="fail2ban.sock" dev=dm-0 ino=46104622 scontext=system_u:system_r:logrotate_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:fail2ban_var_run_t:s0 tclass=sock_file

node=mimmi type=SYSCALL msg=audit(1256093424.364:35877): arch=c000003e syscall=42 success=no exit=-13 a0=3 a1=7fff8ea30da0 a2=21 a3=7fff8ea30ac8 items=0 ppid=20771 pid=20772 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="fail2ban-client" exe="/usr/bin/python" subj=system_u:system_r:logrotate_t:s0-s0:c0.c1023 key=(null)
========================================
node=mimmi type=AVC msg=audit(1256137860.543:36149): avc:  denied  { read write } for  pid=2640 comm="iptables" path="socket:[1507684]" dev=sockfs ino=1507684 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket

node=mimmi type=AVC msg=audit(1256137860.543:36149): avc:  denied  { read write } for  pid=2640 comm="iptables" path="socket:[1507701]" dev=sockfs ino=1507701 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket

node=mimmi type=AVC msg=audit(1256137860.543:36149): avc:  denied  { read write } for  pid=2640 comm="iptables" path="socket:[1507692]" dev=sockfs ino=1507692 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:fail2ban_t:s0 tclass=unix_dgram_socket

node=mimmi type=AVC msg=audit(1256137860.543:36149): avc:  denied  { read write } for  pid=2640 comm="iptables" path="socket:[1507809]" dev=sockfs ino=1507809 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket

node=mimmi type=AVC msg=audit(1256137860.543:36149): avc:  denied  { read write } for  pid=2640 comm="iptables" path="socket:[1507752]" dev=sockfs ino=1507752 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket

node=mimmi type=AVC msg=audit(1256137860.543:36149): avc:  denied  { read write } for  pid=2640 comm="iptables" path="socket:[1507879]" dev=sockfs ino=1507879 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket

node=mimmi type=AVC msg=audit(1256137860.543:36149): avc:  denied  { read write } for  pid=2640 comm="iptables" path="socket:[1507935]" dev=sockfs ino=1507935 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=unconfined_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket

node=mimmi type=SYSCALL msg=audit(1256137860.543:36149): arch=c000003e syscall=59 success=yes exit=0 a0=1b2b350 a1=1b2a5e0 a2=1b2a310 a3=7fff10f75db0 items=0 ppid=2639 pid=2640 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=37 comm="iptables" exe="/sbin/iptables" subj=unconfined_u:system_r:iptables_t:s0 key=(null)
========================================
node=mimmi type=AVC msg=audit(1256137860.810:36151): avc:  denied  { read write } for  pid=2652 comm="sendmail" path="socket:[1507684]" dev=sockfs ino=1507684 scontext=unconfined_u:system_r:system_mail_t:s0 tcontext=unconfined_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket

node=mimmi type=AVC msg=audit(1256137860.810:36151): avc:  denied  { read write } for  pid=2652 comm="sendmail" path="socket:[1507701]" dev=sockfs ino=1507701 scontext=unconfined_u:system_r:system_mail_t:s0 tcontext=unconfined_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket

node=mimmi type=AVC msg=audit(1256137860.810:36151): avc:  denied  { read write } for  pid=2652 comm="sendmail" path="socket:[1507692]" dev=sockfs ino=1507692 scontext=unconfined_u:system_r:system_mail_t:s0 tcontext=unconfined_u:system_r:fail2ban_t:s0 tclass=unix_dgram_socket

node=mimmi type=AVC msg=audit(1256137860.810:36151): avc:  denied  { read write } for  pid=2652 comm="sendmail" path="socket:[1507809]" dev=sockfs ino=1507809 scontext=unconfined_u:system_r:system_mail_t:s0 tcontext=unconfined_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket

node=mimmi type=AVC msg=audit(1256137860.810:36151): avc:  denied  { read write } for  pid=2652 comm="sendmail" path="socket:[1507752]" dev=sockfs ino=1507752 scontext=unconfined_u:system_r:system_mail_t:s0 tcontext=unconfined_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket

node=mimmi type=AVC msg=audit(1256137860.810:36151): avc:  denied  { read write } for  pid=2652 comm="sendmail" path="socket:[1507879]" dev=sockfs ino=1507879 scontext=unconfined_u:system_r:system_mail_t:s0 tcontext=unconfined_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket

node=mimmi type=AVC msg=audit(1256137860.810:36151): avc:  denied  { read write } for  pid=2652 comm="sendmail" path="socket:[1507935]" dev=sockfs ino=1507935 scontext=unconfined_u:system_r:system_mail_t:s0 tcontext=unconfined_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket

node=mimmi type=SYSCALL msg=audit(1256137860.810:36151): arch=c000003e syscall=59 success=yes exit=0 a0=1e49580 a1=1e49c20 a2=1e49a60 a3=7fff4e61b0e0 items=0 ppid=2648 pid=2652 auid=503 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=51 sgid=51 fsgid=51 tty=(none) ses=37 comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=unconfined_u:system_r:system_mail_t:s0 key=(null)
Comment 9 Axel Thimm 2009-10-24 01:58:19 EDT
*** Bug 526485 has been marked as a duplicate of this bug. ***
Comment 10 Axel Thimm 2009-10-26 12:10:59 EDT
*** Bug 530876 has been marked as a duplicate of this bug. ***
Comment 11 Axel Thimm 2009-10-31 04:55:26 EDT
*** Bug 532103 has been marked as a duplicate of this bug. ***
Comment 12 Axel Thimm 2009-11-20 13:46:07 EST
*** Bug 539576 has been marked as a duplicate of this bug. ***
Comment 13 Axel Thimm 2009-11-21 12:05:49 EST
*** Bug 539577 has been marked as a duplicate of this bug. ***
Comment 14 Jonathan Underwood 2010-01-02 21:50:42 EST
Created attachment 381344 [details]
Set socket file descriptor in AsyncServer.start to be CLOEXEC

This should prevent one of the leaked file descriptors which should remove a number of the selinux denials. Have submitted this upstream, but would be good to test it in the Fedora package too.
Comment 15 Jonathan Underwood 2010-01-02 21:59:06 EST
*** Bug 550798 has been marked as a duplicate of this bug. ***
Comment 16 Jonathan Underwood 2010-01-07 19:20:57 EST
Dan: a lot of the still existing selinux messages are of this type:

Jan  7 23:59:00 m1210 setroubleshoot: SELinux is preventing /usr/sbin/sendmail.sendmail access to a leaked unix_dgram_socket file descriptor. For complete SELinux messages. run sealert -l a694a0fe-77c2-4568-8e83-9b8bb06e1e27

which I think arise due to the fact that fail2ban is piping stuff to sendmail. For example, looking at /etc/fail2ban/action.d/sendmail.conf:

actionstart = printf %%b "Subject: [Fail2Ban] <name>: started
              From: Fail2Ban <<sender>>
              To: <dest>\n
              Hi,\n
              The jail <name> has been started successfully.\n
              Regards,\n
              Fail2Ban" | /usr/sbin/sendmail -f <sender> <dest>

failban substitutes values in for <sender> etc, and then execs the command. Is this something that needs allowing in the selinux policy?
Comment 17 Daniel Walsh 2010-01-08 09:57:59 EST
Yes.

Miroslav please add

	fail2ban_rw_stream_sockets(sendmail_t)

########################################
## <summary>
##	Read and write to an fail2ban unix stream socket.
## </summary>
## <param name="domain">
##	<summary>
##	Domain allowed access.
##	</summary>
## </param>
#
interface(`fail2ban_rw_stream_sockets',`
	gen_require(`
		type fail2ban_t;
	')

	allow $1 fail2ban_t:unix_stream_socket { getattr read write ioctl };
')

to F11, F12, RHEL5
Comment 18 Miroslav Grepl 2010-01-08 10:32:20 EST
Added to selinux-policy-3.6.32-68.fc12.noarch
Comment 19 Jonathan Underwood 2010-01-08 10:52:03 EST
Could you update F-11 policy as well? Thanks.
Comment 20 Miroslav Grepl 2010-01-08 13:52:21 EST
Sure, I will add it also to F11 policy.
Comment 21 Miroslav Grepl 2010-01-11 07:09:40 EST
Fixed in selinux-policy-3.6.12-94.fc11.noarch
Comment 22 Fedora Update System 2010-01-19 15:03:42 EST
selinux-policy-3.6.12-94.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/selinux-policy-3.6.12-94.fc11
Comment 23 Fedora Update System 2010-01-20 19:11:19 EST
selinux-policy-3.6.12-94.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update selinux-policy'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2010-0851
Comment 24 Arthur Dent 2010-01-30 10:50:10 EST
OK - There's something strange going on here.

I have a 0.8.4 version of F2B installed from source on my F11 box. It has not been patched with Jonathan Underwood's patches at this stage [1]. 

A few months ago I switched from using gamin to polling mode and removed my local selinux policies which had kept F2B going prior to that and was surprised to find that I got no AVC denials - at all.

I decided however to try the 3.6.12-94-fc11 policy and installed it. I now get AVCs on startup and each time F2B bans something. Examples below.

[1] I have however patched the files on a F11 test rig and I still get AVCs on that (but different ones...)

AVC1
====
SELinux is preventing sendmail (system_mail_t) "read write" fail2ban_t. 
Detailed Description
[SELinux is in permissive mode, the operation would have been denied but was permitted due to permissive mode.]

SELinux denied access requested by sendmail. It is not expected that this access is required by sendmail and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. 


Allowing Access
You can generate a local policy module to allow this access - see FAQ Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report against this package. 
Additional Information

Source Context:  	system_u:system_r:system_mail_t:s0
Target Context:  	system_u:system_r:fail2ban_t:s0
Target Objects:  	socket [ unix_stream_socket ]
Source:  	sendmail
Source Path:  	/usr/sbin/sendmail.sendmail
Port:  	<Unknown>
Host:  	mydomain.com
Source RPM Packages:  	sendmail-8.14.3-5.fc11
Target RPM Packages:  	
Policy RPM:  	selinux-policy-3.6.12-94.fc11
Selinux Enabled:  	True
Policy Type:  	targeted
MLS Enabled:  	True
Enforcing Mode:  	Permissive
Plugin Name:  	catchall
Host Name:  	mydomain.com
Platform:  	Linux mydomain.com 2.6.30.10-105.2.4.fc11.i686.PAE #1 SMP Tue Jan 19 22:46:27 UTC 2010 i686 i686
Alert Count:  	14
First Seen:  	Sat Jan 23 07:15:15 2010
Last Seen:  	Sat Jan 30 13:21:42 2010
Local ID:  	6caba636-c75a-495c-95c7-f0a1dc2a7e4d
Line Numbers:  	

Raw Audit Messages :

node=mydomain.com type=AVC msg=audit(1264857702.292:105): avc: denied { read write } for pid=2778 comm="sendmail" path="socket:[16819]" dev=sockfs ino=16819 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket 
node=mydomain.com type=SYSCALL msg=audit(1264857702.292:105): arch=40000003 syscall=11 success=yes exit=0 a0=9bd0510 a1=9bd0528 a2=9bd0738 a3=9bd0528 items=0 ppid=2774 pid=2778 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=51 sgid=51 fsgid=51 tty=(none) ses=4294967295 comm="sendmail" exe="/usr/sbin/sendmail.sendmail" subj=system_u:system_r:system_mail_t:s0 key=(null) 


AVC2
====
Summary
SELinux is preventing iptables (iptables_t) "read write" fail2ban_t. 
Detailed Description
[SELinux is in permissive mode, the operation would have been denied but was permitted due to permissive mode.]

SELinux denied access requested by iptables. It is not expected that this access is required by iptables and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. 


Allowing Access
You can generate a local policy module to allow this access - see FAQ Or you can disable SELinux protection altogether. Disabling SELinux protection is not recommended. Please file a bug report against this package. 
Additional Information

Source Context:  	system_u:system_r:iptables_t:s0
Target Context:  	system_u:system_r:fail2ban_t:s0
Target Objects:  	socket [ unix_stream_socket ]
Source:  	iptables
Source Path:  	/sbin/iptables
Port:  	<Unknown>
Host:  	mydomain.com
Source RPM Packages:  	iptables-1.4.3.1-1.fc11
Target RPM Packages:  	
Policy RPM:  	selinux-policy-3.6.12-94.fc11
Selinux Enabled:  	True
Policy Type:  	targeted
MLS Enabled:  	True
Enforcing Mode:  	Permissive
Plugin Name:  	catchall
Host Name:  	mydomain.com
Platform:  	Linux mydomain.com 2.6.30.10-105.2.4.fc11.i686.PAE #1 SMP Tue Jan 19 22:46:27 UTC 2010 i686 i686
Alert Count:  	14
First Seen:  	Sat Jan 23 07:15:14 2010
Last Seen:  	Sat Jan 30 13:21:41 2010
Local ID:  	17ce05dc-5d9a-4131-b9d1-183c24bb4659
Line Numbers:  	

Raw Audit Messages :

node=mydomain.com type=AVC msg=audit(1264857701.37:104): avc: denied { read write } for pid=2768 comm="iptables" path="socket:[16819]" dev=sockfs ino=16819 scontext=system_u:system_r:iptables_t:s0 tcontext=system_u:system_r:fail2ban_t:s0 tclass=unix_stream_socket 
node=mydomain.com type=SYSCALL msg=audit(1264857701.37:104): arch=40000003 syscall=11 success=yes exit=0 a0=94173e0 a1=9417618 a2=94166f8 a3=9417618 items=0 ppid=2767 pid=2768 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="iptables" exe="/sbin/iptables" subj=system_u:system_r:iptables_t:s0 key=(null)
Comment 25 Daniel Walsh 2010-02-01 12:05:40 EST
These are fail2ban leaked sockets.
Comment 26 Fedora Update System 2010-02-04 20:15:58 EST
selinux-policy-3.6.12-94.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 27 Fedora Update System 2010-02-14 11:32:58 EST
fail2ban-0.8.4-24.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/fail2ban-0.8.4-24.fc11
Comment 28 Fedora Update System 2010-02-14 11:33:07 EST
fail2ban-0.8.4-24.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/fail2ban-0.8.4-24.fc12
Comment 29 Axel Thimm 2010-02-14 11:42:05 EST
*** Bug 548648 has been marked as a duplicate of this bug. ***
Comment 30 Fedora Update System 2010-02-16 08:17:14 EST
fail2ban-0.8.4-24.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 31 Fedora Update System 2010-02-16 08:19:29 EST
fail2ban-0.8.4-24.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 32 ILMostro 2014-12-14 17:25:04 EST
So, aside from generating a local policy for fail2ban, there's nothing else possible to resolve the issue with the AVC denials, correct?  Perhaps an alternative software package to fail2ban is needed.  Any suggestions or a proposed fix for this bug? This is still an issue with the latest version fail2ban-0.9-9.

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