Bug 972368 - libvirtd inserts iptable rules at the beginning of the iptables chain, making it impossible to secure the network from virtual machines
libvirtd inserts iptable rules at the beginning of the iptables chain, making...
Status: CLOSED DUPLICATE of bug 533193
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
unspecified
All Linux
unspecified Severity high
: ---
: ---
Assigned To: Libvirt Maintainers
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-08 18:48 EDT by Mikulas Patocka
Modified: 2015-03-17 12:58 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-03-17 12:58:56 EDT
Type: Bug
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 Mikulas Patocka 2013-06-08 18:48:49 EDT
Description of problem:

At each start or restart, libvirtd inserts its rules at the beginning of iptables
chains FORWARD and POSTROUTING. These automatically inserted rules override any
rules that the administrator have set.

Libvirtd rules should be inserted at the end of the chain, so that the rules set
by the admin are not overriden by libvirtd rules and remain effective.

Version-Release number of selected component (if applicable):
libvirtd (libvirt) 0.8.3 from Debian Squeeze

How reproducible:
always

Steps to Reproduce:

1. start libvirtd

2. set a rule that prevents virtual machines from connecting to some hosts, for
example:
iptables -I FORWARD -d 192.168.0.0/16 -p tcp -j DROP

3. see the FORWARD chain:
# iptables -L FORWARD
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
DROP       tcp  --  anywhere             192.168.0.0/16
ACCEPT     all  --  anywhere             192.168.192.0/24    state RELATED,ESTABLISHED
ACCEPT     all  --  192.168.192.0/24     anywhere
ACCEPT     all  --  anywhere             anywhere
REJECT     all  --  anywhere             anywhere            reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere            reject-with icmp-port-unreachable

4. run a virtual machine, try to connect to some host forbidden by the rule and
make sure that the rule is effective

5. restart libvirtd: /etc/init.d/libvirt-bin restart

6. see the content of the FORWARD chain again - you see that after libvirtd
restart the order of rules has changed
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             192.168.192.0/24    state RELATED,ESTABLISHED
ACCEPT     all  --  192.168.192.0/24     anywhere
ACCEPT     all  --  anywhere             anywhere
REJECT     all  --  anywhere             anywhere            reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere            reject-with icmp-port-unreachable
DROP       tcp  --  anywhere             192.168.0.0/16

7. switch to the virtual machine again and try to make tcp connection - you see
that the DROP rule is no longer effective and the virtual machine can connect
anywhere

Actual results:
Security is compromised - the virtual machine can connect anywhere

Expected results:
The rules that the admin inserted into iptables should be honored. libvirt should
insert it's own rules at the end of the table, not at the beginning.

Additional info:
This happens on Debian Wheezy with libvirtd 0.8.3
Comment 1 Mikulas Patocka 2013-06-08 18:51:34 EDT
It's Debian Squeeze, not Wheezy, I made a mistake in the bug report.
Comment 2 Svetlozar Argirov 2014-01-27 05:25:00 EST
Another problem with the way libvirtd generates the iptables rules is reported as bug against firewalld but IMHO it is libvirtd problem.  I mean this one : 

https://bugzilla.redhat.com/show_bug.cgi?id=995480

I am currently affected by it with on Fedora 20.
Comment 3 Ján Tomko 2015-03-17 12:58:56 EDT

*** This bug has been marked as a duplicate of bug 533193 ***

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