Bug 303811

+++ This bug was initially created as a clone of Bug #235807 +++

Description of problem:
[A]rping is used by the script "/etc/sysconfig/network-scripts/ifup-eth" to
configure ethernet ports during startup. The script yields "Error, some other
host already uses address ..." when SELinux is in enforcing mode but not when in
permissive mode. [A]udit2allow suggests the rule "allow netutils_t sysfs_t:dir
search;" derived from the generated audit messages:

**********
type=AVC msg=audit(1176190782.851:63): avc:  denied  { search } for  pid=4722
comm="arping" name="/" dev=sysfs ino=1 scontext=user_u:system_r:netutils_t:s0
tcontext=system_u:object_r:sysfs_t:s0 tclass=dir

type=SYSCALL msg=audit(1176190782.851:63): arch=c000003e syscall=6 success=no
exit=-13 a0=7fff313f0d80 a1=7fff313f0b60 a2=7fff313f0b60 a3=0 items=0 ppid=4681
pid=4722 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=pts1 comm="arping" exe="/sbin/arping" subj=user_u:system_r:netutils_t:s0
key=(null)

type=AVC msg=audit(1176190782.851:64): avc:  denied  { search } for  pid=4722
comm="arping" name="/" dev=sysfs ino=1 scontext=user_u:system_r:netutils_t:s0
tcontext=system_u:object_r:sysfs_t:s0 tclass=dir

type=SYSCALL msg=audit(1176190782.851:64): arch=c000003e syscall=6 success=no
exit=-13 a0=7fff313f0d80 a1=7fff313f0b60 a2=7fff313f0b60 a3=0 items=0 ppid=4681
pid=4722 auid=501 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=pts1 comm="arping" exe="/sbin/arping" subj=user_u:system_r:netutils_t:s0
key=(null)
**********

Version-Release number of selected component (if applicable):
kernel-2.6.20-1.2943.fc6.x86_64
iputils-20070202-2.fc6.x86_64
selinux-policy-targeted-2.4.6-49.fc6.noarch

-- Additional comment from major.com on 2007-04-10 05:31 EST --
After more analysis, the following module code seems to fix the problem.
##########
module local 1.0;

require {
        class dir { getattr search }; 
        class file { getattr read }; 
        type netutils_t; 
        type sysfs_t; 
        role system_r; 
};

allow netutils_t sysfs_t:dir { getattr search };
allow netutils_t sysfs_t:file { getattr read };
##########

-- Additional comment from marco on 2007-04-10 05:55 EST --
Confirmed on i386 as well. I'm using the following module code:

#######
module local 1.0;

require {
        class capability { sys_tty_config };
        class dir { getattr search };
        class file { getattr read };
        type netutils_t;
        type sysfs_t;
};

allow netutils_t self:capability sys_tty_config;
allow netutils_t sysfs_t:dir { getattr search };
allow netutils_t sysfs_t:file { getattr read };
######

sys_tty_config I think appeared in my logs because I ran a 'service network
restart' (which fails too).

I've updated both selinux-policy and iputils at the same time, so I can't
pinpoint which is which that caused the problem.



-- Additional comment from webmaster on 2007-04-10 07:13 EST --
Confirmed i386.  Its doing this from today's yum update on all my 4 machines. 
They also are all static assigned IPs, no DHCP.

-- Additional comment from webmaster on 2007-04-10 08:03 EST --
After Marco's comment I can confirm its NOT selinux-policy....

Here is my yum log....

Apr 10 09:22:10 Updated: samba-common.i386 3.0.24-4.fc6
Apr 10 09:22:11 Updated: libXfont.i386 1.2.8-1.fc6
Apr 10 09:22:14 Updated: yum.noarch 3.0.5-2.fc6
Apr 10 09:22:15 Updated: brlapi.i386 0.4.1-2.1.fc6
Apr 10 09:22:17 Updated: samba-client.i386 3.0.24-4.fc6
Apr 10 09:22:18 Updated: iputils.i386 20070202-2.fc6
Apr 10 09:22:19 Updated: libXfont-devel.i386 1.2.8-1.fc6
Apr 10 09:22:22 Updated: yum-updatesd.noarch 3.0.5-2.fc6
Apr 10 09:22:32 Updated: samba.i386 3.0.24-4.fc6
Apr 10 09:22:33 Updated: dhclient.i386 12:3.0.5-4.fc6

Its just plain iputils...

I update daily, here is the last selinux-policy
Apr 06 09:18:47 Updated: selinux-policy.noarch 2.4.6-49.fc6

Cheers!

-- Additional comment from dwalsh on 2007-04-10 10:51 EST --
selinux-policy-2.4.6-52.fc6  Has this policy.  Available in testing tonight.

-- Additional comment from edgar.hoch.de on 2007-04-10 16:03
EST --
I installed selinux-policy-2.4.6-52.fc6 and selinux-policy-targeted-2.4.6-52.fc6
on our system, and now eth0 comes up again while booting the system.

So, the updated package solved the problem for me, thanks a lot!

And as bug #235913 is solved in selinux-policy-targeted-2.4.6-54.fc6,
I think that selinux-policy-targeted-2.4.6-54.fc6 and selinux-policy-2.4.6-54.fc6
or a successor package should be released to the normal updates repository
relativ early (or the package iputils-20070202-2.fc6 should be replaced by the
old one), because otherwise many systems running fc6 may have no network
connection on the next reboot.


A tip for all admins to get the network temporary running to get the update:

Set SELinux temporary in permissive mode,
then start the network again.
The get the updated package
(until released you may get it from updates-testing).

setenforce 0
service network restart

# (add "--enablerepo=updates-testing" ONLY while the new package isn't released
to the normal updates repo!)
yum --enablerepo=updates-testing selinux\*


-- Additional comment from tjb on 2007-04-10 16:15 EST --
Another work around I used was to just 'ifup eth0' in /etc/rc.local and restart
applicable network services. This is the lovely catch 22 that causes the most
problems though. A system with no network needs an update to fix the network...

-- Additional comment from bugzilla.panix.com on 2007-04-10 20:06
EST --
I ran into this today as well.  Fortunately I had local access to the box in
question and was able to reason out the selinux permissive mode temporary fix. 
This bug needs to be fixed and rolled out pronto before it bites those folks
that update and reboot their boxes on a routine basis.  Fortunately(?) automatic
updates still seem to be broken :)  

-- Additional comment from edgar.hoch.de on 2007-04-10 20:36
EST --
I just installed
  selinux-policy-2.4.6-54.fc6
  selinux-policy-targeted-2.4.6-54.fc6
and it works for our machines.
Network eth0 starts on boot with static addresses.


-- Additional comment from bugzilla.panix.com on 2007-04-10 20:47
EST --
I ran into this today as well.  Fortunately I had local access to the box in
question and was able to reason out the selinux permissive mode temporary fix. 
This bug needs to be fixed and rolled out pronto before it bites those folks
that update and reboot their boxes on a routine basis.  Fortunately(?) automatic
updates still seem to be broken :)  

-- Additional comment from webmaster on 2007-04-11 05:10 EST --
Fixed - confirmed 100%.  First up this morning I did a yum update and the new
selinux policy fixed all the machines!  I rebooted and confirmed the ethernet
adapter was NOT disabled and networking came up as usual with selinux enforcing
as normal.

If your not finding this make sure you have got selinux-policy-2.4.6-54.fc6,
maybe yum clean all and yum update.

Sometimes I have to do a clean all and update a few times as not all the
repositories are always synced, but you end up seeing updated packages.


-- Additional comment from d.rye.uk on 2007-09-24 12:45 EST --
Updated a Fedora 6 server with selinux targeted enforcing, on Friday 21
September 2007 and have the same symptoms as at the start of this bug.

Post update have.
egrep "selinux|iputils" /var/log/rpmpkgs
iputils-20070202-3.fc6.i386.rpm
libselinux-1.33.4-2.fc6.i386.rpm
libselinux-python-1.33.4-2.fc6.i386.rpm
selinux-policy-2.4.6-88.fc6.noarch.rpm
selinux-policy-targeted-2.4.6-88.fc6.noarch.rpm

from local console :-(
setenforce 0
service network restart
Gets the network interface back online.......

So it look like this bug back again.