Summary: SELinux is preventing /sbin/iptables-multi "read" access on /var/log/secure. Detailed Description: [iptables has a permissive type (iptables_t). This access was not denied.] 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 (http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug report. Additional Information: Source Context unconfined_u:system_r:iptables_t:s0 Target Context system_u:object_r:var_log_t:s0 Target Objects /var/log/secure [ file ] Source iptables Source Path /sbin/iptables-multi Port <Unknown> Host (removed) Source RPM Packages iptables-1.4.7-2.fc13 Target RPM Packages Policy RPM selinux-policy-3.7.19-41.fc13 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name catchall Host Name (removed) Platform Linux (removed) 2.6.33.6-147.2.4.fc13.i686.PAE #1 SMP Fri Jul 23 17:21:06 UTC 2010 i686 i686 Alert Count 3 First Seen Sun 08 Aug 2010 08:53:51 PM CDT Last Seen Sun 08 Aug 2010 08:53:51 PM CDT Local ID c2910572-a32c-43cc-8af1-1895f8195be4 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1281318831.590:60650): avc: denied { read } for pid=12053 comm="iptables" path="/var/log/secure" dev=dm-0 ino=8913654 scontext=unconfined_u:system_r:iptables_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file node=(removed) type=SYSCALL msg=audit(1281318831.590:60650): arch=40000003 syscall=11 success=yes exit=0 a0=8633d60 a1=86340b8 a2=8634238 a3=86340b8 items=0 ppid=12050 pid=12053 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=3246 comm="iptables" exe="/sbin/iptables-multi" subj=unconfined_u:system_r:iptables_t:s0 key=(null) Hash String generated from catchall,iptables,iptables_t,var_log_t,file,read audit2allow suggests: #============= iptables_t ============== allow iptables_t var_log_t:file read;
I received this alert after restarting the fail2ban service. I made a change to number of connection attempts to sshd that are allowed to fail before a ban is put in place: [root@circe fail2ban]# diff jail.conf.20100808 jail.conf 7a8,12 > ### CHANGELOG ### > # > # 08-AUG-2010, CCB -- Decreased the number of attempts sshd will allow from > # 5 to 3. > # 57c62 < maxretry = 5 --- > maxretry = 3 [root@circe fail2ban]# I then restarted the service: [root@circe fail2ban]# service fail2ban restart Stopping fail2ban: [ OK ] Starting fail2ban: [ OK ] [root@circe fail2ban]# This alert was immediately received. I am using the 3.7.19-41 release of SE Linux policy: [root@circe fail2ban]# rpm -q selinux-policy selinux-policy-3.7.19-41.fc13.noarch [root@circe fail2ban]#
Which version of fail2ban do you use? You can dontaudit it using # grep iptables_t /var/log/audit/audit.log | audit2allow -D -M fail2banleak # semodule -i fail2banleak.pp
I'm using fail2ban version 0.8.4-24. [cbell@circe ~]$ rpm -q fail2ban fail2ban-0.8.4-24.fc13.noarch [cbell@circe ~]$ Thank you for the tip! I'm curious with the possibility of not auditing this behavior, why the bug is closed as can't fix? Should it be opened against selinux-policy instead?
Actually, it is open against selinux-policy... Anyway, the question remains. :-)
There are no iptables_t entries in audit.log. That said, when I restarted the jail this time, there was no alert. The last alert was during the last reboot 4 days ago. [root@circe ~]# service fail2ban restart Stopping fail2ban: [ OK ] Starting fail2ban: [ OK ] [root@circe ~]# grep iptables_t /var/log/audit/audit.log [root@circe ~]#