Bug 235807 - ethernet initialization using arping fails after update to iputils-20070202-2.fc6.x86_64
ethernet initialization using arping fails after update to iputils-20070202-2...
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
6
x86_64 Linux
medium Severity urgent
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
: Reopened
: 303811 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-10 04:47 EDT by major
Modified: 2007-11-30 17:12 EST (History)
6 users (show)

See Also:
Fixed In Version: Current
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-09 16:51:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description major 2007-04-10 04:47:47 EDT
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
Comment 1 major 2007-04-10 05:31:45 EDT
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 };
##########
Comment 2 Marco Colombo 2007-04-10 05:55:36 EDT
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.

Comment 3 David 2007-04-10 07:13:37 EDT
Confirmed i386.  Its doing this from today's yum update on all my 4 machines. 
They also are all static assigned IPs, no DHCP.
Comment 4 David 2007-04-10 08:03:53 EDT
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!
Comment 5 Daniel Walsh 2007-04-10 10:51:09 EDT
selinux-policy-2.4.6-52.fc6  Has this policy.  Available in testing tonight.
Comment 6 Edgar Hoch 2007-04-10 16:03:17 EDT
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\*
Comment 7 Thomas J. Baker 2007-04-10 16:15:14 EDT
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...
Comment 8 Bennett Feitell 2007-04-10 20:06:36 EDT
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 :)  
Comment 9 Edgar Hoch 2007-04-10 20:36:24 EDT
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.
Comment 10 Bennett Feitell 2007-04-10 20:47:15 EDT
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 :)  
Comment 11 David 2007-04-11 05:10:07 EDT
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.
Comment 12 tobias braeutigam 2007-04-11 05:19:40 EDT
I still have the problem even with the fix.
What logfiles etc do you require for analysis?

Greetings Tobias
Comment 13 David 2007-04-11 05:26:31 EDT
Are you using static or dhcp addresses?  If your using dhcp then there still
must be a bug with regards to dhcp.  I am using static addresses.
Comment 14 tobias braeutigam 2007-04-11 06:04:29 EDT
My settings are:

$>ifconfig

eth0      Link encap:Ethernet  Hardware Adresse 00:C0:9F:2A:3D:81
          inet Adresse:192.168.10.31  Bcast:192.168.10.255  Maske:255.255.255.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Basisadresse:0xecc0 Speicher:fe120000-fe140000

eth1      Link encap:Ethernet  Hardware Adresse 00:02:B3:D9:E8:1A
          inet Adresse:192.168.10.32  Bcast:192.168.10.255  Maske:255.255.255.0
          inet6 Adresse: fe80::202:b3ff:fed9:e81a/64 
Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2003 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1636 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:481351 (470.0 KiB)  TX bytes:330994 (323.2 KiB)

lo        Link encap:Lokale Schleife
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6 Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:2038 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2038 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0
          RX bytes:5863176 (5.5 MiB)  TX bytes:5863176 (5.5 MiB)

$>route

Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
192.168.10.0    *               255.255.255.0   U     0      0        0 eth1
192.168.10.0    *               255.255.255.0   U     0      0        0 eth0
169.254.0.0     *               255.255.0.0     U     0      0        0 eth0
default         fritz.fonwlan.b 0.0.0.0         UG    0      0        0 eth1

Only eth0 is connected to the switch. 

The weird thing is, when I deactivate eth1, I cannot connect to the LAN:
eth0 is up (says ifconfig), but when I ping it, I cannot see any 
throughput RX TX packets.

Only when I ifup both eth0 and eth1 I can connect to the LAN/WAN.

I do not use DHCP at all. Only when installing Fedora I used 
DHCP in order to install via PXE boot. This was disabled 
directly after fedora was ready to run. 

I work with Linux since 1997 and the network still bothers me ;)
Comment 15 Edgar Hoch 2007-04-11 07:18:28 EDT
To Comment #12, #13, #14:

Tobias, your problem has nothing to do with this bug.
It is simply a routing problem.
Your default route is configured to use eth1.
If you deactivate eth1 and don't correct the default route
(for example, to use eth0), then it is the normal behaviour
that you have no connection to other networks than your local network.

So, the updated packages still resolves the problem,
and can (and should, I think) released very soon.

Thanks to Daniel Walsh for the fast response and quick resolution.
Comment 16 J. David Rye 2007-09-24 12:45:21 EDT
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.
Comment 17 Daniel Walsh 2007-09-24 17:04:14 EDT
Are you seeing avc messages in /var/log/audit/audit.log?
Comment 18 Daniel Walsh 2007-09-24 17:07:13 EDT
*** Bug 303811 has been marked as a duplicate of this bug. ***
Comment 19 maricar 2007-09-26 04:43:48 EDT
after trying the iputils, SELinux settings and updates, we still enounter this
networking bug. Below are the information regarding the installed applications.

machine architecture: i686
kernel.i686 2.6.20-1.2952.fc6
selinux-policy.noarch 2.4.6-88.fc6
selinux-policy-targeted.noarch 2.4.6-88.fc6
iputils.i386 20070202-3.fc6
policycoreutils.i386 1.34.1-9.fc6
Comment 20 Daniel Walsh 2007-09-26 09:33:08 EDT
Please attach the avc messages from /var/log/audit/audit.log?
Comment 21 maricar 2007-09-27 05:57:51 EDT
There's no log...
Comment 22 J. David Rye 2007-09-27 09:16:11 EDT
Adding a local rule set as suggested  back in april provides a workaround now as
well.

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

Deny messages in log were

type=AVC msg=audit(1190648140.119:460): avc:  denied  { search } for  pid=9730
comm="arping" name="/" dev=sysfs ino=1 scontext=root:system_r:netutils_t:s0
tcontext=system_u:object_r:sysfs_t:s0 tclass=dir
type=AVC msg=audit(1190648140.121:461): avc:  denied  { search } for  pid=9730
comm="arping" name="/" dev=sysfs ino=1 scontext=root:system_r:netutils_t:s0
tcontext=system_u:object_r:sysfs_t:s0 tclass=dir
type=AVC msg=audit(1190648219.265:462): avc:  denied  { search } for  pid=10123
comm="arping" name="/" dev=sysfs ino=1 scontext=root:system_r:netutils_t:s0
tcontext=system_u:object_r:sysfs_t:s0 tclass=dir
type=AVC msg=audit(1190648219.267:463): avc:  denied  { search } for  pid=10123
comm="arping" name="/" dev=sysfs ino=1 scontext=root:system_r:netutils_t:s0
tcontext=system_u:object_r:sysfs_t:s0 tclass=dir
type=AVC msg=audit(1190648458.991:72): avc:  denied  { search } for  pid=2838
comm="arping" name="/" dev=sysfs ino=1 scontext=root:system_r:netutils_t:s0
tcontext=system_u:object_r:sysfs_t:s0 tclass=dir
type=AVC msg=audit(1190648458.993:73): avc:  denied  { search } for  pid=2838
comm="arping" name="/" dev=sysfs ino=1 scontext=root:system_r:netutils_t:s0
tcontext=system_u:object_r:sysfs_t:s0 tclass=dir
type=AVC msg=audit(1190648483.514:76): avc:  denied  { search } for  pid=3203
comm="arping" name="/" dev=sysfs ino=1 scontext=root:system_r:netutils_t:s0
tcontext=system_u:object_r:sysfs_t:s0 tclass=dir
type=AVC msg=audit(1190648483.514:76): avc:  denied  { getattr } for  pid=3203
comm="arping" name="eth0" dev=sysfs ino=5635
scontext=root:system_r:netutils_t:s0 tcontext=system_u:object_r:sysfs_t:s0
tclass=dir
type=AVC msg=audit(1190648483.517:77): avc:  denied  { getattr } for  pid=3203
comm="arping" name="broadcast" dev=sysfs ino=5647
scontext=root:system_r:netutils_t:s0 tcontext=system_u:object_r:sysfs_t:s0
tclass=file
type=AVC msg=audit(1190648483.519:78): avc:  denied  { read } for  pid=3203
comm="arping" name="broadcast" dev=sysfs ino=5647
scontext=root:system_r:netutils_t:s0 tcontext=system_u:object_r:sysfs_t:s0
tclass=file
 
Comment 23 Daniel Walsh 2007-10-09 16:51:30 EDT
Fixed in 	selinux-policy-2.4.6-94.fc6

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