Bug 723862

Summary: "isolated" network is not actually isolated due to dns-tunneling via dnsmasq
Product: Red Hat Enterprise Linux 6 Reporter: nizamov.shawkat
Component: libvirtAssignee: Laine Stump <laine>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: high Docs Contact:
Priority: high    
Version: 6.2CC: dallan, dyuan, mzhan, rwu, veillard, whuang, xhu
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: libvirt-0.9.4-1.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-12-06 11:17:30 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:
Attachments:
Description Flags
tcpdump for libvirt-0.9.3-8.el6
none
tcpdump for libvirt-0.9.4-1.el6 none

Description nizamov.shawkat 2011-07-21 12:14:28 UTC 
There are 3 possible network connections in libvirt:
1) bridge  
2) NAT
3) isolated (guest-host only)

Former two obviously have an access to the network. Latter is said to be isolated from network and serves for connection between host and guest only. However, there is no way to disable dnsmasq in libvirt, therefore, guest always has a working dns connection (if host has it of course). In this case one can not prevent guest from creating dns tunnel over working dnsmasq instance. That means that "isolation" is easily broken from the guest by simple dns-tunneling technique. 

In one of bugreports lack of control over dnsmasq was said to be by design: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/247583

Of course, there are possible workarounds for such particular cases, but they are all external to libvirt. If libvirt claims that connection is isolated than it should really do it (or at least allow to do so) without resorting to external trickery. Please, allow the easy way of disabling dnsmasq in libvirt.
Comment 2 Laine Stump 2011-07-22 04:16:55 UTC 
Rather than disabling dnsmasq, how about just isolating its DNS server? If we run dnsmasq with --no-resolv, it will then satisfy dns requests for names that it knows about (via static host entries in the <dhcp> section, host entries in the <dns> section, and host names learned from clients), but it will not forward any requests for unknown names to any other DNS server - it will just return failures for those requests.

This will allow interested parties to setup fully functional isolated environments without needing a separate DNS server.
Comment 3 nizamov.shawkat 2011-07-22 10:17:02 UTC 
If you are asking my opinion, then, yes - disabling DNS requests forwarding for isolated networks is really a much better and simpler solution.
Comment 4 Laine Stump 2011-07-29 21:28:07 UTC 
A fix for this problem has been pushed to libvirt's upstream git repository, and will be included in the upcoming release 0.9.4:

commit 513122ae93be9e21fd809a100580ce6fbb4e0ba5
Author: Laine Stump <laine>
Date:   Fri Jul 29 15:42:04 2011 -0400

    network: don't forward DNS requests from isolated networks
Comment 6 dyuan 2011-08-05 07:36:59 UTC 
Reproduced this bug with libvirt-0.8.3-8.el6.

# virsh net-dumpxml br1
<network>
  <name>br1</name>
  <uuid>bd74236a-34ce-aa65-bcad-22d197632f9d</uuid>
  <bridge name='br1' stp='on' delay='0' />
  <mac address='52:54:00:24:1B:77'/>
  <ip address='192.168.144.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.144.2' end='192.168.144.254' />
    </dhcp>
  </ip>
</network>

# ps aux|grep dnsmasq
nobody   31984  0.0  0.0  12940   596 ?        S    02:59   0:00 /usr/sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/br1.pid --conf-file= --except-interface lo --dhcp-option=3 --listen-address 192.168.144.1 --dhcp-range 192.168.144.2,192.168.144.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/br1.leases --dhcp-lease-max=253 --dhcp-no-override

ping google.com in guest.

catch the pkgs
# tcpdump -i br1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br1, link-type EN10MB (Ethernet), capture size 65535 bytes
03:09:40.163516 IP 192.168.144.43.36522 > 192.168.144.1.domain: 60838+ A? google.com. (28)
03:09:40.163849 ARP, Request who-has 192.168.144.43 tell 192.168.144.1, length 28
03:09:40.164031 ARP, Reply 192.168.144.43 is-at 52:54:00:81:9c:88 (oui Unknown), length 28
03:09:40.164037 IP 192.168.144.1.domain > 192.168.144.43.36522: 60838 6/0/0 A 74.125.93.105, A 74.125.93.104, A 74.125.93.103, A 74.125.93.99, A 74.125.93.147, A 74.125.93.106 (124)


Verified PASS with libvirt-0.9.4-1.el6, all dns query is refused.
qemu-kvm-0.12.1.2-2.176.el6
kernel-2.6.32-176.el6

# ps aux|grep dnsmasq
nobody   30549  0.0  0.0  12940   568 ?        S    02:48   0:00 /usr/sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/br1.pid --conf-file= --except-interface lo --dhcp-option=3 --no-resolv --listen-address 192.168.144.1 --dhcp-range 192.168.144.2,192.168.144.254 --dhcp-leasefile=/var/lib/libvirt/dnsmasq/br1.leases --dhcp-lease-max=253 --dhcp-no-override

ping google.com in guest.

# tcpdump -i br1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br1, link-type EN10MB (Ethernet), capture size 65535 bytes
03:29:13.122275 IP 192.168.144.43.45622 > 192.168.144.1.domain: 34185+ A? google.com. (28)
03:29:13.122368 IP 192.168.144.1.domain > 192.168.144.43.45622: 34185 Refused 0/0/0 (28)
03:29:13.122526 IP 192.168.144.43.42169 > 192.168.144.1.domain: 34185+ A? google.com. (28)
03:29:13.122561 IP 192.168.144.1.domain > 192.168.144.43.42169: 34185 Refused 0/0/0 (28)
03:29:13.122732 IP 192.168.144.43.36311 > 192.168.144.1.domain: 38270+ A? google.com.localdomain. (40)
03:29:13.122757 IP 192.168.144.1.domain > 192.168.144.43.36311: 38270 Refused 0/0/0 (40)
03:29:13.122840 IP 192.168.144.43.49294 > 192.168.144.1.domain: 38270+ A? google.com.localdomain. (40)
03:29:13.122856 IP 192.168.144.1.domain > 192.168.144.43.49294: 38270 Refused 0/0/0 (40)
03:29:18.121576 ARP, Request who-has 192.168.144.43 tell 192.168.144.1, length 28
03:29:18.121708 ARP, Reply 192.168.144.43 is-at 52:54:00:81:9c:88 (oui Unknown), length 28
Comment 7 dyuan 2011-08-05 07:39:21 UTC 
Created attachment 516835 [details]
tcpdump for libvirt-0.9.3-8.el6
Comment 8 dyuan 2011-08-05 07:39:49 UTC 
Created attachment 516836 [details]
tcpdump for libvirt-0.9.4-1.el6
Comment 9 errata-xmlrpc 2011-12-06 11:17:30 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-2011-1513.html