Bug 504738 - Packets are lost when transfer from bridge to physical nic
Packets are lost when transfer from bridge to physical nic
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy (Show other bugs)
5.4
All Linux
urgent Severity urgent
: rc
: ---
Assigned To: Daniel Walsh
BaseOS QE
:
: 504572 (view as bug list)
Depends On: 504572
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-09 00:43 EDT by Perry Myers
Modified: 2016-04-26 10:00 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 504572
Environment:
Last Closed: 2009-09-02 03:57:45 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)
audit.log (576.09 KB, text/x-log)
2009-06-11 10:46 EDT, Qixiang Wan
no flags Details
dmesg.log (25.58 KB, text/x-log)
2009-06-11 10:47 EDT, Qixiang Wan
no flags Details
command lines to reproduce bz:504738 (3.77 KB, text/x-log)
2009-06-11 10:48 EDT, Qixiang Wan
no flags Details
dmesg.log ( qemu/kvm user mode networking ) (23.14 KB, text/x-log)
2009-06-21 06:36 EDT, Qixiang Wan
no flags Details
audit.log (qemu/kvm user mode networking) (28.84 KB, text/x-log)
2009-06-21 06:37 EDT, Qixiang Wan
no flags Details

  None (edit)
Description Perry Myers 2009-06-09 00:43:48 EDT
+++ This bug was initially created as a clone of Bug #504572 +++

Description of problem:
packets are lost when transfer from bridge to physical nic

Version-Release number of selected component (if applicable):
Red Hat Enterprise Virtualization Hypervisor release 2.2-2.TEST.TEST.20090602.beta1.el5ovirt

How reproducible:
100%

Steps to Reproduce:
1. start a guest on RHEV 2.2-2.TEST.TEST.20090602.beta1.el5ovirt
use the an virtul nic in host's bridge as it's nic.
2. ping from another host (in the same sub net with host in step 1) to the guest

An example environment:

126.10.1.22 : a host ( RHEV-2.2-2.TEST.TEST.20090602.beta1.el5ovirt)
126.10.1.33 : a guest (rhel-server-5.3 x86_64) which run on host 126.10.1.22
126.10.1.1 : another host (rhel-server-5.3 x86_64)

Actual results:
126.10.1.1 cannot get the icmp replies from 126.10.1.33

126.10.1.22 can communicate with 126.10.1.33
126.10.1.1 can communicate with 126.10.1.22 well
but 126.10.1.1 cannot communicate with 126.10.1.33.

Expected results:
126.10.1.1 should get the replies from 126.10.1.33

Additional info:

126.10.1.22 : a host ( RHEV-2.2-2.TEST.TEST.20090602.beta1.el5ovirt)
126.10.1.33 : a guest (rhel-server-5.3 x86_64) which run on 126.10.1.22
126.10.1.1 : another host (rhel-server-5.3 x86_64)


host (126.10.1.22) environmet:
-----------------------------------------------------------------------
$ brctl show
bridge name	bridge id		STP enabled	interfaces
breth0		8000.00237d53abd1	no		rtl8139_10_1
							eth0

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
126.10.1.0      0.0.0.0         255.255.255.0   U     0      0        0 breth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 breth0

$ iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination      

$ ifconfig

breth0    Link encap:Ethernet  HWaddr 00:23:7D:53:AB:D1  
          inet addr:126.10.1.22  Bcast:126.10.1.255  Mask:255.255.255.0
          inet6 addr: fe80::223:7dff:fe53:abd1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3163645 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1455675 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:1739470617 (1.6 GiB)  TX bytes:8879234278 (8.2 GiB)

eth0      Link encap:Ethernet  HWaddr 00:23:7D:53:AB:D1  
          inet6 addr: fe80::223:7dff:fe53:abd1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3165680 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6948396 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1797052579 (1.6 GiB)  TX bytes:9269544068 (8.6 GiB)
          Interrupt:209 Memory:d8800000-d8810000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:11769 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11769 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:1945547 (1.8 MiB)  TX bytes:1945547 (1.8 MiB)

rtl8139_10_1 Link encap:Ethernet  HWaddr CA:59:B4:60:4B:79  
          inet6 addr: fe80::c859:b4ff:fe60:4b79/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:403 errors:0 dropped:0 overruns:0 frame:0
          TX packets:167615 errors:0 dropped:1 overruns:133 carrier:0
          collisions:0 txqueuelen:500 
          RX bytes:53940 (52.6 KiB)  TX bytes:10465998 (9.9 MiB)
-----------------------------------------------------------------------

guest (126.10.1.33) environment:

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
126.10.1.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0

$ iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:23:45:67:AB:00  
          inet addr:126.10.1.33  Bcast:126.10.1.255  Mask:255.255.255.0
          inet6 addr: fe80::223:45ff:fe67:ab00/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:143443 errors:0 dropped:129 overruns:0 frame:0
          TX packets:593 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:6887876 (6.5 MiB)  TX bytes:83624 (81.6 KiB)
          Interrupt:10 Base address:0x4000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1116 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1116 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:3808928 (3.6 MiB)  TX bytes:3808928 (3.6 MiB)
-----------------------------------------------------------------------


The guest is created by using vdsm, use the rtl8139_10_1 which in bridge breth0 as it's nic. And guest can get it's ip (126.10.1.33) from DHCP server well.

Listen on eth0 and breth0 of 126.10.1.22 (host), eth0 of 126.10.1.33 (guest), then on 126.10.1.1 (another host) issue the command:

$ ping -c5 126.10.1.33
PING 126.10.1.33 (126.10.1.33) 56(84) bytes of data.

--- 126.10.1.33 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4000ms

-----------------------------------------------------------------------
Listen on eth0 of guest (126.10.1.33):

$ tcpdump -nn -i eth0 icmp and host 126.10.1.1 and host 126.10.1.33

05:36:16.969909 IP 126.10.1.1 > 126.10.1.33: ICMP echo request, id 44591, seq 1, length 64
05:36:16.970095 IP 126.10.1.33 > 126.10.1.1: ICMP echo reply, id 44591, seq 1, length 64
05:36:17.967002 IP 126.10.1.1 > 126.10.1.33: ICMP echo request, id 44591, seq 2, length 64
05:36:17.967021 IP 126.10.1.33 > 126.10.1.1: ICMP echo reply, id 44591, seq 2, length 64
05:36:18.966859 IP 126.10.1.1 > 126.10.1.33: ICMP echo request, id 44591, seq 3, length 64
05:36:18.966877 IP 126.10.1.33 > 126.10.1.1: ICMP echo reply, id 44591, seq 3, length 64
05:36:19.967428 IP 126.10.1.1 > 126.10.1.33: ICMP echo request, id 44591, seq 4, length 64
05:36:19.967449 IP 126.10.1.33 > 126.10.1.1: ICMP echo reply, id 44591, seq 4, length 64
05:36:20.966592 IP 126.10.1.1 > 126.10.1.33: ICMP echo request, id 44591, seq 5, length 64
05:36:20.966614 IP 126.10.1.33 > 126.10.1.1: ICMP echo reply, id 44591, seq 5, length 64

10 packets captured
10 packets received by filter
0 packets dropped by kernel
-----------------------------------------------------------------------
Listen on breth0 of host (126.10.1.22):

$ tcpdump -nn -i breth0 icmp and host 126.10.1.1 and host 126.10.1.33

09:36:14.863365 IP 126.10.1.1 > 126.10.1.33: ICMP echo request, id 44591, seq 1, length 64
09:36:14.864449 IP 126.10.1.33 > 126.10.1.1: ICMP echo reply, id 44591, seq 1, length 64
09:36:15.862028 IP 126.10.1.1 > 126.10.1.33: ICMP echo request, id 44591, seq 2, length 64
09:36:15.862721 IP 126.10.1.33 > 126.10.1.1: ICMP echo reply, id 44591, seq 2, length 64
09:36:16.862048 IP 126.10.1.1 > 126.10.1.33: ICMP echo request, id 44591, seq 3, length 64
09:36:16.862803 IP 126.10.1.33 > 126.10.1.1: ICMP echo reply, id 44591, seq 3, length 64
09:36:17.862108 IP 126.10.1.1 > 126.10.1.33: ICMP echo request, id 44591, seq 4, length 64
09:36:17.863216 IP 126.10.1.33 > 126.10.1.1: ICMP echo reply, id 44591, seq 4, length 64
09:36:18.862131 IP 126.10.1.1 > 126.10.1.33: ICMP echo request, id 44591, seq 5, length 64
09:36:18.862955 IP 126.10.1.33 > 126.10.1.1: ICMP echo reply, id 44591, seq 5, length 64

10 packets captured
10 packets received by filter
0 packets dropped by kernel
-----------------------------------------------------------------------
Listen on rtl8139_10_1 of host (126.10.1.22):

$ tcpdump -nn icmp -i rtl8139_10_1 and host 126.10.1.1 and host 126.10.1.33

09:36:14.863758 IP 126.10.1.1 > 126.10.1.33: ICMP echo request, id 44591, seq 1, length 64
09:36:14.864449 IP 126.10.1.33 > 126.10.1.1: ICMP echo reply, id 44591, seq 1, length 64
09:36:15.862058 IP 126.10.1.1 > 126.10.1.33: ICMP echo request, id 44591, seq 2, length 64
09:36:15.862721 IP 126.10.1.33 > 126.10.1.1: ICMP echo reply, id 44591, seq 2, length 64
09:36:16.862081 IP 126.10.1.1 > 126.10.1.33: ICMP echo request, id 44591, seq 3, length 64
09:36:16.862803 IP 126.10.1.33 > 126.10.1.1: ICMP echo reply, id 44591, seq 3, length 64
09:36:17.862165 IP 126.10.1.1 > 126.10.1.33: ICMP echo request, id 44591, seq 4, length 64
09:36:17.863216 IP 126.10.1.33 > 126.10.1.1: ICMP echo reply, id 44591, seq 4, length 64
09:36:18.862177 IP 126.10.1.1 > 126.10.1.33: ICMP echo request, id 44591, seq 5, length 64
09:36:18.862955 IP 126.10.1.33 > 126.10.1.1: ICMP echo reply, id 44591, seq 5, length 64

10 packets captured
10 packets received by filter
0 packets dropped by kernel

-----------------------------------------------------------------------

Listen on eth0 of host (126.10.1.22):

$ tcpdump -nn -i eth0 icmp and host 126.10.1.1 and host 126.10.1.33

09:36:14.863564 IP 126.10.1.1 > 126.10.1.33: ICMP echo request, id 44591, seq 1, length 64
09:36:15.862028 IP 126.10.1.1 > 126.10.1.33: ICMP echo request, id 44591, seq 2, length 64
09:36:16.862048 IP 126.10.1.1 > 126.10.1.33: ICMP echo request, id 44591, seq 3, length 64
09:36:17.862108 IP 126.10.1.1 > 126.10.1.33: ICMP echo request, id 44591, seq 4, length 64
09:36:18.862131 IP 126.10.1.1 > 126.10.1.33: ICMP echo request, id 44591, seq 5, length 64

5 packets captured
11 packets received by filter
0 packets dropped by kernel


Misc:
This defect happen on both RHEV-2.2-2.TEST.TEST.20090602.beta1.el5ovirt and ovirt-node-snap-16.TEST.TEST
This defect doesn't happen on RHEL-Server-5.3 server. 
This defect doesn't happen on RHEV-2.1-2.beta2.el5ovirt.

--- Additional comment from qwan@redhat.com on 2009-06-08 06:19:16 EDT ---

$ ps -ef | grep qemu-kvm | grep -v grep

vdsm      7181  6114  0 08:20 ?        00:00:00 /bin/sh -c sudo /usr/bin/tunctl -d rtl8139_10_1; sudo /usr/bin/tunctl -b -u vdsm -t rtl8139_10_1;/usr/bin/sudo /sbin/ip link set dev rtl8139_10_1 up;/usr/bin/sudo /usr/sbin/brctl addif breth0 rtl8139_10_1;nice -n 20 /usr/bin/qemu-kvm -no-hpet -usbdevice tablet  -rtc-td-hack  -localtime  -m 1024  -boot c  -net nic,vlan=1,macaddr=00:23:45:67:AB:00,model=rtl8139 -net tap,vlan=1,ifname=rtl8139_10_1,script=no  -hda /rhev/data-center/0d07c837-96e3-4d85-ab63-4ffdc00ca15a/f6ce65fb-36a0-43d5-80c5-f2c5bc3bf830/images/5504b713-1fd4-42de-9b90-74e0a2233142/f80719bb-1cd2-48c4-8f0d-0a95f730b6e3 -pidfile /var/vdsm/4b4d8646-8e08-43c7-9f14-9f4b35042173.pid -vnc 0:10,password  -smbios type=1,manufacturer="Red Hat",product="Red Hat Enterprise Virtualization Hypervisor",version=2.2-2.TEST.TEST.20090602.beta1.el5ovirt,serial=6B379E1E-F605-DE11-BBDA-7D53ABD10023,uuid=4b4d8646-8e08-43c7-9f14-9f4b35042173  -vmchannel di:0200,unix:/var/vdsm/4b4d8646-8e08-43c7-9f14-9f4b35042173.guest.socket,server -monitor unix:/var/vdsm/4b4d8646-8e08-43c7-9f14-9f4b35042173.monitor.socket,server 1>/var/vdsm/4b4d8646-8e08-43c7-9f14-9f4b35042173.stdio.dump 2>&1; sudo /usr/bin/tunctl -d rtl8139_10_1; 
vdsm      7190  7181 33 08:20 ?        00:21:46 /usr/bin/qemu-kvm -no-hpet -usbdevice tablet -rtc-td-hack -localtime -m 1024 -boot c -net nic,vlan=1,macaddr=00:23:45:67:AB:00,model=rtl8139 -net tap,vlan=1,ifname=rtl8139_10_1,script=no -hda /rhev/data-center/0d07c837-96e3-4d85-ab63-4ffdc00ca15a/f6ce65fb-36a0-43d5-80c5-f2c5bc3bf830/images/5504b713-1fd4-42de-9b90-74e0a2233142/f80719bb-1cd2-48c4-8f0d-0a95f730b6e3 -pidfile /var/vdsm/4b4d8646-8e08-43c7-9f14-9f4b35042173.pid -vnc 0:10,password -smbios type=1,manufacturer=Red Hat,product=Red Hat Enterprise Virtualization Hypervisor,version=2.2-2.TEST.TEST.20090602.beta1.el5ovirt,serial=6B379E1E-F605-DE11-BBDA-7D53ABD10023,uuid=4b4d8646-8e08-43c7-9f14-9f4b35042173 -vmchannel di:0200,unix:/var/vdsm/4b4d8646-8e08-43c7-9f14-9f4b35042173.guest.socket,server -monitor unix:/var/vdsm/4b4d8646-8e08-43c7-9f14-9f4b35042173.monitor.socket,server

--- Additional comment from apevec@redhat.com on 2009-06-08 06:26:50 EDT ---

(In reply to comment #0)
> This defect happen on both RHEV-2.2-2.TEST.TEST.20090602.beta1.el5ovirt and
> ovirt-node-snap-16.TEST.TEST
> This defect doesn't happen on RHEL-Server-5.3 server. 
> This defect doesn't happen on RHEV-2.1-2.beta2.el5ovirt.  

This is a blocker for 5.4 based beta then.

--- Additional comment from qwan@redhat.com on 2009-06-08 07:41:00 EDT ---

> This defect doesn't happen on RHEL-Server-5.3 server. 
(In reply to comment #2)
> (In reply to comment #0)
> > This defect happen on both RHEV-2.2-2.TEST.TEST.20090602.beta1.el5ovirt and
> > ovirt-node-snap-16.TEST.TEST
> > This defect doesn't happen on RHEL-Server-5.3 server. 
> > This defect doesn't happen on RHEV-2.1-2.beta2.el5ovirt.  
> 
> This is a blocker for 5.4 based beta then.  

>> This defect doesn't happen on RHEL-Server-5.3 server. 
sorry, should be RHEL-Server-5.4 server, haven't tried on RHEL-Server-5.3 server.

--- Additional comment from apevec@redhat.com on 2009-06-08 12:34:07 EDT ---

Jun  8 16:22:18 vpro2 kernel: type=1400 audit(1244478138.069:14): avc:  denied  { sendto } for  pid=17500 comm="qemu-kvm" saddr=172.31.0.200 daddr=172.31.0.32 netif=breth0 scontext=system_u:object_r:unlabeled_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=association

Red Hat Enterprise Virtualization Hypervisor release 2.2-2.TEST.TEST.20090602.beta1.el5ovirt
has selinux-policy-2.4.6-236.el5

Dan, could you help us interpreting and suggesting the proper fix for the above AVC ?


Question for qwan:
(In reply to comment #3)
> >> This defect doesn't happen on RHEL-Server-5.3 server. 
> sorry, should be RHEL-Server-5.4 server, haven't tried on RHEL-Server-5.3
> server.  

RHEL-Server-5.4 server where this works for you, is it selinux enabled?

--- Additional comment from apevec@redhat.com on 2009-06-08 12:38:32 EDT ---

btw, AVC I got is with libvirt created guest, but error is at the qemu-kvm level so it shouldn't matter, but qwan please check for selinux messages on your node.

--- Additional comment from apevec@redhat.com on 2009-06-08 12:52:23 EDT ---

Forgot to mention, setenforce 0 on host makes ping come through, I can big guest from another station on the same LAN and vice versa.

--- Additional comment from eparis@redhat.com on 2009-06-08 13:42:51 EDT ---

scontext=.....unlabeled_t is a major problem....

It's something I'm probably going to have to dig into, but I'm not going to be back in the office till wednesday, dan, maybe you can find a way to get sds at the NSA involved without giving away company confidential info...

--- Additional comment from apevec@redhat.com on 2009-06-08 13:43:38 EDT ---

With -236 policy qemu-kvm inherits virtd_t from libvirtd,
which was fixed in selinux-policy >= -238, where qemu-kvm runs under qemu_t.
But still getting the same AVC blocking { sendto } from qemu-kvm
(tested with selinux-policy-2.4.6-242.el5)

BTW, qemu-kvm is moved to /usr/libexec/qemu-kvm
bug 489654 bug 503955
so policy needs to be fixed again...

--- Additional comment from dwalsh@redhat.com on 2009-06-08 13:52:52 EDT ---

Changed path in selinux-policy-2.4.6-243.el5

--- Additional comment from qwan@redhat.com on 2009-06-08 23:06:47 EDT ---

(In reply to comment #4)
> 
> RHEL-Server-5.4 server where this works for you, is it selinux enabled?  

this defect can be found on RHEL-Server-5.4 too. The node I tried has selinux disabled. Changed the selinux to enabled and got the same problem.
Comment 2 Daniel Walsh 2009-06-09 16:16:19 EDT
This is a kernel issue because there should be no unlabeled_t file processes on the the system.  S

Have you seen this problem since.  Is this continuing to happen?  Or was this after an upgrade and the qemu process was already running?
Comment 3 Qixiang Wan 2009-06-11 04:52:04 EDT
I cannot reproduce this defect on RHEL-5.4 with kvm-83-74.el5 and kvm-83-72.el5
too. selinux-policy is 2.4.6-243 and 2.4.6-242.
linux-2.6.18-152.el5
working on that to find the reason now. will let you know ASAP.
Comment 4 Qixiang Wan 2009-06-11 10:46:54 EDT
Created attachment 347418 [details]
audit.log
Comment 5 Qixiang Wan 2009-06-11 10:47:29 EDT
Created attachment 347419 [details]
dmesg.log
Comment 6 Qixiang Wan 2009-06-11 10:48:38 EDT
Created attachment 347421 [details]
command lines to reproduce bz:504738
Comment 7 Herbert Xu 2009-06-17 02:50:19 EDT
Hmm, so does this happen with SELinux off or not? If it only occurs with SELinux enabled then someone who knows more about that would be able to deal with this much better than I.
Comment 8 Qixiang Wan 2009-06-17 03:09:18 EDT
It happens on kernel-2.6.18-151.el5 with selinux enforcing.
need selinux-policy-2.4.6-243.el5 or lower version as workaround added in 2.4.6.244.

But didn't find this defect on kernel-2.6.18.152.el5 with selinux enforing/Permissive/ or disabled.
Comment 9 Linda Wang 2009-06-17 08:40:53 EDT
so this may have been fixed by the latest selinux-policy pkg?
Comment 10 Stephen Smalley 2009-06-17 09:01:00 EDT
My impression is that the latest policy has a workaround (to allow unlabeled_t traffic), but that the actual bug is in the kernel, as there should never be such unlabeled_t traffic in the first place.  Regression in the networking stack, possibly something amiss in the backported labeled IPSEC patches?
Comment 11 Paul Moore 2009-06-18 16:12:58 EDT
Is there a source RPM for the kernel mentioned above somewhere that I can fetch?
Comment 12 Eric Paris 2009-06-18 16:27:15 EDT
I pointed paul at some kernel source.
Comment 13 Paul Moore 2009-06-18 19:56:18 EDT
Have you tried this using the userspace stack of KVM/QEMU?  I'm trying to determine if this only happens when the guest uses a bridged interface.
Comment 14 Paul Moore 2009-06-19 17:04:40 EDT
I suspect this problem is specific to guests using a TAP device to gain full network access (I would really appreciate it if the original reporter could verify that this only happens when a TAP device is used, see comment #13).  From what I can tell so far the issue appears to be that the TUN/TAP driver in the kernel allocates a sock structure to send network traffic and the corresponding SELinux state for that sock structure is never setup beyond the basic initialization that comes from the sock allocation call; this is almost certainly why we are seeing the unlabeled_t in the logs.

At this point I'm not sure what the "best" fix is for this problem.  If the policy can't be tweaked for RHEL5.x then another quick solution would be to check skb->dev in the SELinux postroute hook and pass the packet if it is coming from a TUN/TAP device - that _should_ work but I haven't tried it.

Long term, i.e. mainline, neither of the fixes mentioned above seem like a good idea.  Ideally we would want the sock created by the TUN/TAP driver to reflect the label of the process creating the TUN/TAP device (I think we can use current() safely here since these are ioctls) but that is going to require some new LSM hooks and there is an issue regarding persistence of TUN/TAP devices in this case.  I need to think about this some more and post something to the relevant lists to get feedback.
Comment 16 Qixiang Wan 2009-06-21 06:31:18 EDT
tried the user mode networking:

Host environment:

kernel-2.6.18-151.el5    ( as mentioned in previous comment, this defect is not found on -152 kernel)
selinux-policy-2.4.6-243.el5
kvm-83-69.el5ovirt


$ getenforce 
Enforcing

$ brctl show
bridge name	bridge id		STP enabled	interfaces
breth0		8000.00237d53abd1	no		eth0

$ ifconfig
breth0    Link encap:Ethernet  HWaddr 00:23:7D:53:AB:D1  
          inet addr:10.66.70.199  Bcast:10.66.70.255  Mask:255.255.255.0
          inet6 addr: fe80::223:7dff:fe53:abd1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6592 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7190 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:472735 (461.6 KiB)  TX bytes:3974434 (3.7 MiB)

eth0      Link encap:Ethernet  HWaddr 00:23:7D:53:AB:D1  
          inet6 addr: fe80::223:7dff:fe53:abd1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:7359 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8623 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:646345 (631.1 KiB)  TX bytes:4106227 (3.9 MiB)
          Interrupt:193 Memory:d8800000-d8810000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:560 (560.0 b)  TX bytes:560 (560.0 b)


create a vm with user mode networking:
$ qemu-kvm -drive file=rhel5.3-x64.qcow2,index=0,media=disk,if=ide,boot=on -net user -net nic,model=rtl8139,macaddr=00:01:02:03:04:05  -m 1024 -vnc :10 -monitor stdio

in guest:
$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:01:02:03:04:05  
          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
          inet6 addr: fe80::201:2ff:fe03:405/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:212 errors:0 dropped:0 overruns:0 frame:0
          TX packets:322 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:35122 (34.2 KiB)  TX bytes:33608 (32.8 KiB)
          Interrupt:11 Base address:0x4000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:560 (560.0 b)  TX bytes:560 (560.0 b)

$ wget www.google.com
--06:30:16--  http://www.google.com/
Resolving www.google.com... 64.233.189.147, 64.233.189.99, 64.233.189.104
Connecting to www.google.com|64.233.189.147|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: `index.html'

     0K .....                                                  2.35M=0.002s

06:30:16 (2.35 MB/s) - `index.html' saved [5263]

the guest can access the host 10.66.70.199 and other hosts as expected. When listen on the breth0 and eth0 on host, both can see the packets.
Comment 17 Qixiang Wan 2009-06-21 06:36:02 EDT
Created attachment 348782 [details]
dmesg.log  ( qemu/kvm user mode networking )
Comment 18 Qixiang Wan 2009-06-21 06:37:31 EDT
Created attachment 348784 [details]
audit.log (qemu/kvm user mode networking)

on host: 

$ ls -lZ /usr/bin/qemu-kvm
lrwxrwxrwx  root root system_u:object_r:bin_t          /usr/bin/qemu-kvm

$ ps -efZ | grep qemu-kvm | grep -v grep
root:system_r:unconfined_t:SystemLow-SystemHigh root 3190 3085  2 17:54 pts/0 00:01:06 qemu-kvm -drive file=rhel5.3-x64.qcow2,index=0,media=disk,if=ide,boot=on -net user -net nic,model=rtl8139,macaddr=00:01:02:03:04:05 -m 1024 -vnc :10 -monitor stdio
Comment 19 Mark McLoughlin 2009-07-09 05:04:04 EDT
(In reply to comment #16)
> ( as mentioned in previous comment, this defect is not found on -152 kernel)

Is this bug fixed in -152, then?

Does anyone know what commit fixed it?
Comment 20 Linda Wang 2009-07-09 14:34:36 EDT
*** Bug 504572 has been marked as a duplicate of this bug. ***
Comment 21 Daniel Walsh 2009-07-23 11:56:39 EDT
I have no idea why this bug is assigned to me.
Comment 23 Eric Paris 2009-07-23 13:37:13 EDT
We needed a policy change to get things working for 5.4 and I believe Dan did that.  This is the best fix available for 5.4.  An upstream kernel fix is in the works but won't be ready for 5.4 and might not be suitable for RHEL5 at all.  The policy fix is the way to go for now.  I don't know which BZ is for the policy fix and which BZ is for the kernel fix, but I really think we need 2.

-Eric
Comment 24 Daniel Walsh 2009-07-23 13:47:42 EDT
Fixed in selinux-policy-2.4.6-253.el5

fdef(`targeted_policy',`
	allow unlabeled_t self:filesystem associate;
	allow unlabeled_t self:association sendto;
')
Comment 31 errata-xmlrpc 2009-09-02 03:57:45 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1242.html

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