Bug 769674 - libvirt adds iptables rules for bridge device of network with <forward mode='bridge'>
Summary: libvirt adds iptables rules for bridge device of network with <forward mode='...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.2
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: rc
: ---
Assignee: Laine Stump
QA Contact: Virtualization Bugs
URL:
Whiteboard:
: 770964 (view as bug list)
Depends On: 760442
Blocks: CVE-2011-4600
TreeView+ depends on / blocked
 
Reported: 2011-12-21 17:17 UTC by RHEL Program Management
Modified: 2012-05-28 07:11 UTC (History)
14 users (show)

Fixed In Version: libvirt-0.9.4-23.el6_2.2
Doc Type: Bug Fix
Doc Text:
Due to an error in the bridge network driver, libvirt did not respect network configuration properly. Therefore, if a network was set with the "forward" element set to "mode=bridge", libvirt incorrectly added iptables rules for such a network every time the libvirtd daemon was restarted and the network was active. While most of the erroneously added rules were of no significance, two of the rules could allow outside sources access to a private DNS server on the host (if the dns server was configured to listen on all interfaces). With this update, libvirt reloads iptables rules only if the "forward" element is set to "mode=route", "mode=nat", or "mode=none".
Clone Of:
Environment:
Last Closed: 2012-01-17 10:25:31 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:0013 0 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2012-08-03 13:29:55 UTC

Description RHEL Program Management 2011-12-21 17:17:04 UTC
This bug has been copied from bug #760442 and has been proposed
to be backported to 6.2 z-stream (EUS).

Comment 4 Laine Stump 2011-12-21 19:45:03 UTC
A backport of the upstream fix has been posted to rhvirt-patches:

http://post-office.corp.redhat.com/archives/rhvirt-patches/2011-December/msg00430.html

Comment 5 Daniel Veillard 2011-12-31 03:25:06 UTC
*** Bug 770964 has been marked as a duplicate of this bug. ***

Comment 6 Huang Wenlong 2011-12-31 09:08:20 UTC
Verify this bug with libvirt-0.9.4-23.el6_2.2.x86_64

1) save original iptables list
#iptables -v -n -L FORWARD >before.table
2) define a network via libvirt

    virsh net-dumpxml bridge-test
    <network>
    <name>bridge-test</name>
    <uuid>4277dd53-d0b8-4f14-bf00-133c172833ee</uuid>
    <forward mode='bridge'/>
    <bridge name='breth0' />
    <mac address='52:54:00:7D:A8:30'/>
    </network>

3) start "bridge-test" then restart libvirtd
#virsh net-start bridge-test

#service libvirtd restart

4) save new iptables list
#iptables -v -n -L FORWARD >after.table

5) diff iptables list there are some rules for breth0
#diff -uNr before.table after.table
#rpm -q libvirt
libvirt-0.9.9-0rc1.el6.x86_64

no new policy add for bridge .

Comment 7 Huang Wenlong 2011-12-31 09:10:44 UTC
(In reply to comment #6)
> Verify this bug with libvirt-0.9.4-23.el6_2.2.x86_64
> 
> 1) save original iptables list
> #iptables -v -n -L FORWARD >before.table
> 2) define a network via libvirt
> 
>     virsh net-dumpxml bridge-test
>     <network>
>     <name>bridge-test</name>
>     <uuid>4277dd53-d0b8-4f14-bf00-133c172833ee</uuid>
>     <forward mode='bridge'/>
>     <bridge name='breth0' />
>     <mac address='52:54:00:7D:A8:30'/>
>     </network>
> 
> 3) start "bridge-test" then restart libvirtd
> #virsh net-start bridge-test
> 
> #service libvirtd restart
> 
> 4) save new iptables list
> #iptables -v -n -L FORWARD >after.table
> 
> 5) diff iptables list there are some rules for breth0
> #diff -uNr before.table after.table
> #rpm -q libvirt
> libvirt-0.9.9-0rc1.el6.x86_64

libvirt version is 0.9.4-23.el6_2.2.x86_64 not 0.9.9-0rc1.el6.x86_64

> no new policy add for bridge .

Comment 9 Huang Wenlong 2012-01-09 05:58:03 UTC
As Comment 6   this bug is verified .

Comment 10 yuping zhang 2012-01-09 06:50:57 UTC
Verified this issue with:
libvirt-client-0.9.4-23.el6_2.4.x86_64
libvirt-0.9.4-23.el6_2.4.x86_64
libvirt-python-0.9.4-23.el6_2.4.x86_64

Steps
1.# iptables -v -n -L FORWARD 
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination 
    0     0 ACCEPT     all  --  virbr1 virbr1  0.0.0.0/0            0.0.0.0/0   
    0     0 REJECT     all  --  *      virbr1  0.0.0.0/0            0.0.0.0/0  
        reject-with icmp-port-unreachable 
    0     0 REJECT     all  --  virbr1 *       0.0.0.0/0            0.0.0.0/0  
        reject-with icmp-port-unreachable 
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0  
        PHYSDEV match ! --physdev-is-bridged reject-with icmp-host-prohibited 

# cat bridge-test.xml 
  <network>
    <name>bridge-test</name>
    <uuid>4277dd53-d0b8-4f14-bf00-133c172833ee</uuid>
    <forward mode='bridge'/>
    <bridge name='rhevm' />
    <mac address='52:54:00:7D:A8:30'/>
  </network>

# virsh net-define bridge-test.xml 
Network bridge-test defined from bridge-test.xml

# virsh net-start bridge-test
Network bridge-test started

# /etc/init.d/libvirtd restart
Stopping libvirtd daemon:                                  [  OK  ]
Starting libvirtd daemon:                                  [  OK  ]

# iptables -v -n -L FORWARD 
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination 
    0     0 ACCEPT     all  --  virbr1 virbr1  0.0.0.0/0            0.0.0.0/0   
    0     0 REJECT     all  --  *      virbr1  0.0.0.0/0            0.0.0.0/0  
        reject-with icmp-port-unreachable 
    0     0 REJECT     all  --  virbr1 *       0.0.0.0/0            0.0.0.0/0  
        reject-with icmp-port-unreachable 
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0  
        PHYSDEV match ! --physdev-is-bridged reject-with icmp-host-prohibited

Comment 11 errata-xmlrpc 2012-01-17 10:25:31 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0013.html

Comment 12 Miroslav Svoboda 2012-01-17 11:50:22 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Due to an error in the bridge network driver, libvirt did not respect network configuration properly. Therefore, if a network was set with the "forward" element set to "mode=bridge", libvirt incorrectly added iptables rules for such a network every time the libvirtd daemon was restarted and the network was active. This could cause the network to become unaccessible. With this update, libvirt reloads iptables rules only if the "forward" element is set to "mode=route", "mode=nat", or "mode=none".

Comment 13 Laine Stump 2012-01-20 04:14:35 UTC
The effects of the erroneously added rules were improperly described in the Technical Notes. I modified it accordingly.

Comment 14 Laine Stump 2012-01-20 04:14:35 UTC
    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1 @@
-Due to an error in the bridge network driver, libvirt did not respect network configuration properly. Therefore, if a network was set with the "forward" element set to "mode=bridge", libvirt incorrectly added iptables rules for such a network every time the libvirtd daemon was restarted and the network was active. This could cause the network to become unaccessible. With this update, libvirt reloads iptables rules only if the "forward" element is set to "mode=route", "mode=nat", or "mode=none".+Due to an error in the bridge network driver, libvirt did not respect network configuration properly. Therefore, if a network was set with the "forward" element set to "mode=bridge", libvirt incorrectly added iptables rules for such a network every time the libvirtd daemon was restarted and the network was active. While most of the erroneously added rules were of no significance, two of the rules could allow outside sources access to a private DNS server on the host (if the dns server was configured to listen on all interfaces). With this update, libvirt reloads iptables rules only if the "forward" element is set to "mode=route", "mode=nat", or "mode=none".


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