Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I am managing a Red Hat Enterprise 5 system using Chef. Something within sequence of configuration commands is generating selinux alerts such as:

SELinux is preventing iptables (iptables_t) "read" to /superhome/dir (user_home_dir_t).

However when I run "sealert -l", it seems I only see partial information:


Additional Information:

Source Context                root:system_r:iptables_t
Target Context                system_u:object_r:user_home_dir_t
Target Objects                /superhome/redacted [ dir ]
Source                        iptables
Source Path                   /sbin/iptables
Port                          <Unknown>
Source RPM Packages           iptables-1.3.5-5.3.el5_4.1
Target RPM Packages        
Policy RPM                    selinux-policy-2.4.6-316.el5
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Permissive
Plugin Name                   catchall_file
Host Name           
Platform                      Linux 2.6.18-274.el5 #1 SMP
                              Fri Jul 8 17:36:59 EDT 2011 x86_64 x86_64
Alert Count                   17
First Seen                    Tue Jul 31 11:16:38 2012
Last Seen                     Tue Jul 31 18:46:35 2012
Local ID                      6c58ff2c-6cab-4db0-b047-896d6adc8e0f
Line Numbers               

Raw Audit Messages  type=AVC msg=audit(1343774795.973:33819): avc:  denied  { read } for  pid=26444 comm="iptables" path="/superhome/redacted" dev=dm-0 ino=27656194 scontext=root:system_r:iptables_t:s0 tcontext=system_u:object_r:user_home_dir_t:s0 tclass=dir type=SYSCALL msg=audit(1343774795.973:33819): arch=c000003e syscall=59 success=yes exit=0 a0=1ec6c5a0 a1=1ec28360 a2=1ec2b540 a3=8 items=0 ppid=26435 pid=26444 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1500 comm="iptables" exe="/sbin/iptables" subj=root:system_r:iptables_t:s0 key=(null)

Presumably the "Source" command had additional arguments (Note: the exact directory name below "/superhome", and the hostname have been redacted). Is there any way to find out the arguments and/or the full command?

share|improve this question
I can't think of any reason that iptables should be accessing random directories. Are you sure that /a/dir was the actual directory in the alert? –  Michael Hampton Jul 31 '12 at 18:01
OK, can you post the actual directory name? –  Michael Hampton Jul 31 '12 at 22:14
How can you not know that? You already said the output was redacted, so presumably you redacted it yourself (or can find the person who did). –  Michael Hampton Jul 31 '12 at 22:17
You should have posted this at first. It's critical information to answering your question. Please edit your question to include this information. –  Michael Hampton Jul 31 '12 at 22:21
While I'm still thinking about it, also please post any relevant entries from /var/log/audit/audit.log. –  Michael Hampton Jul 31 '12 at 22:22

1 Answer 1

Thanks for posting the additional info.

I did quite a bit of looking into this, and couldn't find any way to reproduce this issue.

I found that iptables doesn't actually have any command line options that would cause it to read a user-supplied file. Nor does its SELinux reference policy define any need to read arbitrary files.

My suspicion at this point is that some files on your target system are mislabeled. This could happen if, for instance, someone was editing a copy of iptables' configuration file in a user home directory and moved it to /etc/sysconfig/iptables instead of copying it. Moving a file preserves its SELinux context, and so it would have the wrong context at its destination. Copying a file creates the new file with the default context for the new location, which is almost always the correct context.

If it is mislabeled files, then running restorecon should fix it right up. To be sure, I'd just relabel the whole filesystem. You can do this without rebooting by running:

restorecon -r -vv /

Or you can just relabel files likely to be affected:

restorecon -r -vv /etc

The -r option makes it recurse, and -vv makes it extra verbose.

It's also possible that a file that iptables wants to read is symlinked to a file in a user's home directory. In the current reference policy, iptables has access to read/write /etc/sysconfig/ip6?tables.*.

One final note: It appears your system has SELinux in permissive mode. This means that these events are logged, but not actually denied. You can restore enforcing mode by running setenforce 1. Then watch to see what breaks. :)

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.