Bug 504738
| Summary: | Packets are lost when transfer from bridge to physical nic | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Perry Myers <pmyers> | ||||||||||||
| Component: | selinux-policy | Assignee: | Daniel Walsh <dwalsh> | ||||||||||||
| Status: | CLOSED ERRATA | QA Contact: | BaseOS QE <qe-baseos-auto> | ||||||||||||
| Severity: | urgent | Docs Contact: | |||||||||||||
| Priority: | urgent | ||||||||||||||
| Version: | 5.4 | CC: | apevec, azarembo, benl, dwalsh, eparis, llim, markmc, mmalik, ovirt-maint, paul.moore, qwan, sdsmall, sghosh, syeghiay | ||||||||||||
| Target Milestone: | rc | ||||||||||||||
| Target Release: | --- | ||||||||||||||
| Hardware: | All | ||||||||||||||
| OS: | Linux | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||
| Clone Of: | 504572 | Environment: | |||||||||||||
| Last Closed: | 2009-09-02 07:57:45 UTC | Type: | --- | ||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||
| Documentation: | --- | CRM: | |||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||
| Embargoed: | |||||||||||||||
| Bug Depends On: | 504572 | ||||||||||||||
| Bug Blocks: | |||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Perry Myers
2009-06-09 04:43:48 UTC
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? 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. Created attachment 347418 [details]
audit.log
Created attachment 347419 [details]
dmesg.log
Created attachment 347421 [details]
command lines to reproduce bz:504738
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. 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. so this may have been fixed by the latest selinux-policy pkg? 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? Is there a source RPM for the kernel mentioned above somewhere that I can fetch? I pointed paul at some kernel source. 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. 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. 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.
Created attachment 348782 [details]
dmesg.log ( qemu/kvm user mode networking )
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
(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? *** Bug 504572 has been marked as a duplicate of this bug. *** I have no idea why this bug is assigned to me. 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 Fixed in selinux-policy-2.4.6-253.el5 fdef(`targeted_policy',` allow unlabeled_t self:filesystem associate; allow unlabeled_t self:association sendto; ') 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 |