Bug 230191

Created attachment 148856 [details]
Configuration file

I should have mentioned the selinux policy version:

selinux-policy-2.4.6-40.fc6
selinux-policy-targeted-2.4.6-40.fc6

Yes, selinux policies from different packages are gathered together. But I'm not
sure I understand the selinux issue at all:

It looks like iptables trying to write into the logfile directly? iptables can
only log through the kernel or netlink. But I'm rather ignorant on selinux
output, so I may be reading it all wrong.

This looks like the terminal output of iptables is being redirected to
/var/log/fail2ban.log  which is labeled var_log_t.

You can use 

grep fail2ban /var/log/audit/audit.log | audit2allow -M myfailtoban 

to create a loadable policy module, load it and the avc messages will stop.

Ah right. That's not a very user friendly solution though :) Is there no way of
fixing this at the package level?

How does fail2ban work?  Is it a script file that is simply doing

iptables ... >> /var/log/fail2ban.log?

If yes, one trick to get around the selinux problem might be.

iptables ... | cat >> /var/log/fail2ban.log

Is fail2ban in fedora-extras?

Yes, fail2ban is in extras. I am not sure exactly how it's working - it's a
daemon that monitors /var/log/secure for failed login attempts, and when it sees
more than a certain number from a given host it runs a command to add a firewall
rule to drop packets from that IP. In the configuration I'm using, it will run
shorewall ban <IP>, and shorewall does the relevant iptables Voodo. It can also
run an iptables command itself, (see fwban and fwunban commands in the
configuration file - sample configurations are in /usr/share/doc/fail2ban).
However, my reading of the error messages is that it is the fail2ban itself 

Is there not a way of adding a module to a package which says to SElinux "Allow
this executable file to write to this log file"? Or must this be done at the
selinux-policy level?

Sorry, I seem to have lost the end of a sentence there -- I meant to write:

However, my reading of the error messages is that it is the fail2ban itself
(i.e. the daemon) which is writing to fail2ban.log (rather than redirecting
stdout), and that is making SElinux grumble.

fail2ban policy has been added to rawhide policy in selinux-policy-2.5.11-4.fc7
Prior actually.

Added fail2ban policy in selinux-policy-2.4.6-64.fc6.src.rpm

Hi Daniel - did you actually push an update for policy 2.4.6-64 on FC-6? on a
fully uypdated FC-6 box today I see:

# rpm -qa | grep selinux
libselinux-1.33.4-2.fc6
selinux-policy-2.4.6-62.fc6
libselinux-1.33.4-2.fc6
selinux-policy-targeted-2.4.6-62.fc6
libselinux-python-1.33.4-2.fc6

Hi - still seeing messages with these versions:

# rpm -qa | grep selinux
selinux-policy-2.4.6-69.fc6
libselinux-1.33.4-2.fc6
libselinux-1.33.4-2.fc6
selinux-policy-targeted-2.4.6-69.fc6
libselinux-python-1.33.4-2.fc6

May 25 08:02:04 withnail kernel: audit(1180076524.636:129): avc:  denied  {
append } for  pid=27851 comm="iptables" name="fa
il2ban.log" dev=sda2 ino=1404512 scontext=user_u:system_r:iptables_t:s0
tcontext=system_u:object_r:fail2ban_log_t:s0 tclass=
file
May 25 08:02:04 withnail kernel: audit(1180076524.637:130): avc:  denied  { read
write } for  pid=27852 comm="iptables" name
="[544036]" dev=sockfs ino=544036 scontext=user_u:system_r:iptables_t:s0
tcontext=user_u:system_r:initrc_t:s0 tclass=unix_st
ream_socket
May 25 08:02:04 withnail kernel: audit(1180076524.637:131): avc:  denied  {
append } for  pid=27852 comm="iptables" name="fa
il2ban.log" dev=sda2 ino=1404512 scontext=user_u:system_r:iptables_t:s0
tcontext=system_u:object_r:fail2ban_log_t:s0 tclass=
file
May 25 08:12:04 withnail kernel: audit(1180077124.847:132): avc:  denied  { read
write } for  pid=27894 comm="iptables" name
="[544036]" dev=sockfs ino=544036 scontext=user_u:system_r:iptables_t:s0
tcontext=user_u:system_r:initrc_t:s0 tclass=unix_st
ream_socket
May 25 08:12:04 withnail kernel: audit(1180077124.847:133): avc:  denied  {
append } for  pid=27894 comm="iptables" name="fa
il2ban.log" dev=sda2 ino=1404512 scontext=user_u:system_r:iptables_t:s0
tcontext=system_u:object_r:fail2ban_log_t:s0 tclass=
file
May 25 08:12:04 withnail kernel: audit(1180077124.850:134): avc:  denied  { read
write } for  pid=27897 comm="iptables" name
="[544036]" dev=sockfs ino=544036 scontext=user_u:system_r:iptables_t:s0
tcontext=user_u:system_r:initrc_t:s0 tclass=unix_st
ream_socket
May 25 08:12:04 withnail kernel: audit(1180077124.850:135): avc:  denied  {
append } for  pid=27897 comm="iptables" name="fa
il2ban.log" dev=sda2 ino=1404512 scontext=user_u:system_r:iptables_t:s0
tcontext=system_u:object_r:fail2ban_log_t:s0 tclass=
file

Still happening?

What is still happening?  Are you still seeing avc messages?

Hi guys, sorry for the delay. I have updated all of my machines to F7 now, and
so am unable to comment as to whether this is still occuring on FC6. However, on
F-7 I can confirm that I do not see avc denied mesages which mentioned fail2ban
such as those above. The only thing I do see related to fail2ban/iptables are
messages like these below, and I am not sure whether or not it is fail2ban which
triggers these (I suspect not actually).

Jun 18 19:25:09 withnail setroubleshoot:      SELinux is preventing
/sbin/iptables (iptables_t) "read wr
ite" to socket:[11164] (initrc_t).      For complete SELinux messages. run
sealert -l 3dac0bc8-b897-478c
-aae3-cf74be1da547
Jun 18 19:35:10 withnail last message repeated 6 times
Jun 18 19:35:10 withnail setroubleshoot:      SELinux is preventing
/sbin/iptables (iptables_t) "read wr
ite" to socket:[11164] (initrc_t).      For complete SELinux messages. run
sealert -l 3dac0bc8-b897-478c
-aae3-cf74be1da547
Jun 18 19:35:18 withnail kernel: Shorewall:SSHA:DROP:IN=eth0 OUT=
MAC=00:19:b9:00:c2:49:00:d0:79:95:98:0
0:08:00 SRC=210.87.191.131 DST=128.40.2.35 LEN=60 TOS=0x00 PREC=0x00 TTL=41
ID=51878 PROTO=TCP SPT=48825
 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0 
Jun 18 19:35:21 withnail setroubleshoot:      SELinux is preventing
/sbin/iptables (iptables_t) "read wr
ite" to socket:[11164] (initrc_t).      For complete SELinux messages. run
sealert -l 3dac0bc8-b897-478c
-aae3-cf74be1da547
Jun 18 19:45:21 withnail last message repeated 6 times
Jun 18 19:45:21 withnail setroubleshoot:      SELinux is preventing
/sbin/iptables (iptables_t) "read wr
ite" to socket:[11164] (initrc_t).      For complete SELinux messages. run
sealert -l 3dac0bc8-b897-478c
-aae3-cf74be1da547

More detail on those messages:

sealert -l 3dac0bc8-b897-478c-aae3-cf74be1da547
Summary
    SELinux is preventing /sbin/iptables (iptables_t) "read write" to
    socket:[11164] (initrc_t).

Detailed Description
    SELinux denied access requested by /sbin/iptables. It is not expected that
    this access is required by /sbin/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
    http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can disable
    SELinux protection altogether. Disabling SELinux protection is not
    recommended. Please file a http://bugzilla.redhat.com/bugzilla/enter_bug.cgi
    against this package.

Additional Information        

Source Context                system_u:system_r:iptables_t
Target Context                system_u:system_r:initrc_t
Target Objects                socket:[11164] [ unix_stream_socket ]
Affected RPM Packages         iptables-1.3.7-2 [application]
Policy RPM                    selinux-policy-2.6.4-14.fc7
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Enforcing
Plugin Name                   plugins.catchall
Host Name                     withnail.phys.ucl.ac.uk
Platform                      Linux withnail.phys.ucl.ac.uk 2.6.21-1.3228.fc7 #1
                              SMP Tue Jun 12 14:56:37 EDT 2007 x86_64 x86_64
Alert Count                   53
First Seen                    Mon Jun 18 19:14:45 2007
Last Seen                     Sat Jun 23 03:49:38 2007
Local ID                      3dac0bc8-b897-478c-aae3-cf74be1da547
Line Numbers                  

Raw Audit Messages            

avc: denied { read, write } for comm="iptables" dev=sockfs egid=0 euid=0
exe="/sbin/iptables" exit=0 fsgid=0 fsuid=0 gid=0 items=0 name="[11164]"
path="socket:[11164]" pid=26771 scontext=system_u:system_r:iptables_t:s0 sgid=0
subj=system_u:system_r:iptables_t:s0 suid=0 tclass=unix_stream_socket
tcontext=system_u:system_r:initrc_t:s0 tty=(none) uid=0

Fixed in selinux-policy-2.6.4-23

Created attachment 160888 [details]
fail2ban selinux alert

I'm getting an alert using fail2ban in fc7 with iptables trying to read
/var/log/secure. See the attachment for details. I'm using the default fail2ban
configuration (block ssh using iptables rules).

fail2ban-0.8.0-9.fc7
selinux-policy-2.6.4-30.fc7

This is a leaked file descriptor by fail2ban.  I am pretty sure iptables is not
trying to read /var/log/secure.  fail2ban is however,  So when it execs iptbales
it is forgetting to closeonexec the open file descriptor, causing selinux to
catch the error.

fcntl(fd, F_SETFD, FD_CLOEXEC)

I communicated with upstream - fail2bane just uses os.system to exec iptables.
Does that fit in the picture? If so what should be done?

I think what Daniel is saying is that after opening a log file, one needs to set
that file descriptor to FD_CLOEXEC so that when iptables is exec'd by the
fail2ban server it doesn't trigger the SElinux warning.

So, in the method __openLogFile(self, filename) in filter.py, something like 

rv = fcntl.fcntl(__crtHandler, fcntl.FD_CLOEXEC, 1)

is needed after self.__crtHandler = open(filename)

I am too tired to test this though - will try later.

Is this still an issue?

Yup, afraid so, I never got back to this one. Will see if i can fix it later.

Created attachment 299356 [details]
stop leaking file descriptors on fork/exec

Patch to make log file descriptors cloexec to stop leaking file descriptors on
fork/exec.

Thanks! rawhide had been updated in time before the F9 window closed. I'll fire
up f7/f8 builds now as well.

(In reply to comment #25)
> Thanks! rawhide had been updated in time before the F9 window closed.

Hm, that was a lie. I though I had submitted this build, but I hadn't. I'll have
to contact releng before building for rawhide.

> I'll fire up f7/f8 builds now as well.

But I can build for these at least.

Problem still exists. I won't clog this up anymore but the relevant thread (if
additional info is needed) is on the fedora-selinux list : Fail2ban and SELINUX

I looked around but this looks like the best place to mention it. If there is a
better place to report this I haven't found it yet. I looked around on
Fail2ban.org but did not see any place to report bugs.

Are you sure the leaking file descriptor problem still exists with the patch I
posted in comment #24? AFAIK Axel's builds with that patch haven't been pushed yet.

Regarding the problem you raise on the selinux list about gam_server (which
stops fail2ban working), that is already reported as BZ #437633.

If the patches haven't been pushed yet then no i am not sure they still exist. I
discovered this quite by accident, hit the selinux list with a few questions and
here we are. I am way behind the curve on this one, when is the patch getting
pushed? I will look in updates testing(probably should have done that already
anyway!)

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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

fail2ban-0.8.2-14.fc8 has been submitted as an update for Fedora 8

fail2ban-0.8.2-14.fc7 has been submitted as an update for Fedora 7

fail2ban-0.8.2-14.fc9 has been submitted as an update for Fedora 9

fail2ban-0.8.2-14.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

fail2ban-0.8.2-14.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.

fail2ban-0.8.2-14.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.