Bug 622341 - SELinux is preventing /sbin/iptables-multi "read" access on /var/log/secure.
Summary: SELinux is preventing /sbin/iptables-multi "read" access on /var/log/sec...
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy   
(Show other bugs)
Version: 13
Hardware: i386 Linux
Target Milestone: ---
Assignee: Miroslav Grepl
QA Contact: Fedora Extras Quality Assurance
Whiteboard: setroubleshoot_trace_hash:a1afe179118...
Depends On:
TreeView+ depends on / blocked
Reported: 2010-08-09 01:55 UTC by Christofer C. Bell
Modified: 2010-10-08 18:28 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-08-10 16:58:55 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Christofer C. Bell 2010-08-09 01:55:24 UTC

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

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)
                     #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;

Comment 1 Christofer C. Bell 2010-08-09 01:58:01 UTC
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
> ### CHANGELOG ###
> #
> # 08-AUG-2010, CCB -- Decreased the number of attempts sshd will allow from
> #                     5 to 3.
> #
< 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
[root@circe fail2ban]#

Comment 2 Miroslav Grepl 2010-08-10 16:58:55 UTC
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

Comment 3 Christofer C. Bell 2010-08-10 22:51:25 UTC
I'm using fail2ban version 0.8.4-24.

[cbell@circe ~]$ rpm -q fail2ban
[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?

Comment 4 Christofer C. Bell 2010-08-10 22:51:59 UTC
Actually, it is open against selinux-policy... Anyway, the question remains. :-)

Comment 5 Christofer C. Bell 2010-08-10 22:54:34 UTC
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 ~]#

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