Bug 522767

*** Bug 518752 has been marked as a duplicate of this bug. ***

*** Bug 505926 has been marked as a duplicate of this bug. ***

*** Bug 483510 has been marked as a duplicate of this bug. ***

(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!

*** Bug 522898 has been marked as a duplicate of this bug. ***

*** Bug 523361 has been marked as a duplicate of this bug. ***

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)

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)

*** Bug 526485 has been marked as a duplicate of this bug. ***

*** Bug 530876 has been marked as a duplicate of this bug. ***

*** Bug 532103 has been marked as a duplicate of this bug. ***

*** Bug 539576 has been marked as a duplicate of this bug. ***

*** Bug 539577 has been marked as a duplicate of this bug. ***

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.

*** Bug 550798 has been marked as a duplicate of this bug. ***

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?

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

Added to selinux-policy-3.6.32-68.fc12.noarch

Could you update F-11 policy as well? Thanks.

Sure, I will add it also to F11 policy.

Fixed in selinux-policy-3.6.12-94.fc11.noarch

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

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

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)

These are fail2ban leaked sockets.

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.

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

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

*** Bug 548648 has been marked as a duplicate of this bug. ***

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.

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.

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.