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
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 }; ##########
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.
Confirmed i386. Its doing this from today's yum update on all my 4 machines. They also are all static assigned IPs, no DHCP.
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!
selinux-policy-2.4.6-52.fc6 Has this policy. Available in testing tonight.
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\*
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...
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 :)
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.
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.
I still have the problem even with the fix. What logfiles etc do you require for analysis? Greetings Tobias
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.
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 ;)
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.
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.
Are you seeing avc messages in /var/log/audit/audit.log?
*** Bug 303811 has been marked as a duplicate of this bug. ***
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
Please attach the avc messages from /var/log/audit/audit.log?
There's no log...
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
Fixed in selinux-policy-2.4.6-94.fc6