Bug 483510 - SELinux is preventing fail2ban-server (fail2ban_t) "connectto" rpm_t. to communicate with gamin
SELinux is preventing fail2ban-server (fail2ban_t) "connectto" rpm_t. to comm...
Status: CLOSED DUPLICATE of bug 522767
Product: Fedora
Classification: Fedora
Component: fail2ban (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Axel Thimm
Fedora Extras Quality Assurance
: 491444 495267 499674 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2009-02-01 19:47 EST by Edgar Hoch
Modified: 2009-09-11 07:08 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-11 07:08:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Source SELinux modul with the missing rule for rpm_t for fail2ban (201 bytes, application/octet-stream)
2009-02-01 19:47 EST, Edgar Hoch
no flags Details

  None (edit)
Description Edgar Hoch 2009-02-01 19:47:52 EST
Created attachment 330568 [details]
Source SELinux modul with the missing rule for rpm_t for fail2ban

Description of problem:
fail2ban cannot communicate with gamin (gam_server).

There is a selinux alert:

node=xxx type=AVC msg=audit(1233524671.874:34129): avc:  denied  { connectto } for  pid=10176 comm="fail2ban-server" path=002F746D702F66616D2D726F6F742D000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 scontext=unconfined_u:system_r:fail2ban_t:s0 tcontext=system_u:system_r:rpm_t:s0 tclass=unix_stream_socket

node=xxx type=SYSCALL msg=audit(1233524671.874:34129): arch=c000003e syscall=42 success=no exit=-13 a0=5 a1=7fff0574d800 a2=6e a3=4 items=0 ppid=1 pid=10176 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1249 comm="fail2ban-server" exe="/usr/bin/python" subj=unconfined_u:system_r:fail2ban_t:s0 key=(null)

audit2allow suggests the following rule:

allow fail2ban_t rpm_t:unix_stream_socket connectto;

I have made a selinux module with this rule and have installed it.
Now fail2ban-server is working (with jail ssh-iptables).

I am wondering why the socket seems to have selinux file context rpm_t.
I found no file for the socket so I just can't verify it against a selinux rule.
It would be better to set the socket to the right context (if rpm_t is wrong) instead of creating the rule above but I don't know how to find it and which rule is wrong.

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


How reproducible:

Steps to Reproduce:
1. Install package fail2ban.
   Use the standard configuration in /etc/fail2ban/ .
2. Start fail2ban: service fail2ban start
3. Get the status: service fail2ban status
   The number of jails is shown as zero.
4. Have a lock at /var/log/fail2ban.log .
   There are message like

2009-02-01 22:44:30,597 fail2ban.server : INFO   Changed logging target to /var/log/fail2ban.log for Fail2ban v0.8.3
2009-02-01 22:44:30,598 fail2ban.jail   : INFO   Creating new jail 'ssh-iptables'
2009-02-01 22:44:30,598 fail2ban.jail   : INFO   Jail 'ssh-iptables' uses Gamin
2009-02-01 22:44:31,875 fail2ban.comm   : WARNING Invalid command: ['add', 'ssh-iptables', 'auto']

5. Install the selinux module with the rule above.
   semodule -i imsfail2ban.pp

6. Restart or reload fail2ban.
   service fail2ban reload

7. Have a lock at /var/log/fail2ban.log .
   Now there are message like

2009-02-02 00:44:09,487 fail2ban.server : INFO   Changed logging target to /var/log/fail2ban.log for Fail2ban v0.8.3
2009-02-02 00:44:09,489 fail2ban.jail   : INFO   Creating new jail 'ssh-iptables'
2009-02-02 00:44:09,489 fail2ban.jail   : INFO   Jail 'ssh-iptables' uses Gamin
2009-02-02 00:44:09,493 fail2ban.filter : INFO   Added logfile = /var/log/secure
2009-02-02 00:44:09,495 fail2ban.filter : INFO   Set maxRetry = 5
2009-02-02 00:44:09,498 fail2ban.filter : INFO   Set findtime = 600
2009-02-02 00:44:09,499 fail2ban.actions: INFO   Set banTime = 600
2009-02-02 00:44:09,639 fail2ban.jail   : INFO   Jail 'ssh-iptables' started

   and fail2ban is working.
Comment 1 Daniel Walsh 2009-02-02 10:02:04 EST
This is a leaked file descriptor that you are seeing when the fail2ban service is updated and the rpm post install restarts the service.  It can be ignored.  You should also not use Gamin for this, use polling in stead.  Gamin was a service added for uses not services.
Comment 2 Axel Thimm 2009-02-02 14:36:02 EST
I thought this was fixed some time ago:

* Fri Mar 28 2008 Axel Thimm <Axel.Thimm@ATrpms.net> - 0.8.2-14
- Close on exec fixes by Jonathan Underwood.

But maybe there are more open files left and a similar bug is triggered.

Do I need to do anything to the current package?
Comment 3 Daniel Walsh 2009-04-11 08:29:31 EDT
*** Bug 495267 has been marked as a duplicate of this bug. ***
Comment 4 Edgar Hoch 2009-04-11 09:26:28 EDT
Dear Daniel, der Axel,

sorry for the late reply. I use fail2ban with polling like advised in comment #1.
It works fine for me, thanks!

Axel, it would be fine if the default for fail2ban could changed to polling (for "backend = auto") and the documentation and comments in the config files are changed appropriate, so that new users don't run into the same problem.

- The source code should be changed to interpret "backend = auto" as "backend = polling".
  This may affect /usr/share/fail2ban/server/jail.py* .

- The comment in /etc/fail2ban/jail.conf should reflect the source code change.
  It also may be mentioned that gamin was designed for users not services.
  This may affect /etc/fail2ban/jail.conf .

This changes best should be done against the mainstream source.
Apart from this changes this bug can be closed.

Thanks and best regards
Comment 5 Jonathan Underwood 2009-05-23 18:38:22 EDT
This is basically a design problem with fail2ban. Gamin isn't actually meant to
be used in this way. I reported this upstream some time ago:

Comment 6 Jonathan Underwood 2009-05-23 18:39:02 EDT
*** Bug 491444 has been marked as a duplicate of this bug. ***
Comment 7 Jonathan Underwood 2009-05-23 18:39:33 EDT
*** Bug 499674 has been marked as a duplicate of this bug. ***
Comment 8 Jonathan Underwood 2009-05-23 18:42:39 EDT
See also
Comment 9 Axel Thimm 2009-09-11 07:08:11 EDT

*** This bug has been marked as a duplicate of bug 522767 ***

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