[libvirt] [PATCH 3/3] network: use dnsmasq --bind-dynamic when available

[Gene Czarcinski]

On 11/21/2012 09:55 PM, Laine Stump wrote:
> This bug resolves CVE-2012-3411, which is described in the following
> bugzilla report:
>
>    https://bugzilla.redhat.com/show_bug.cgi?id=833033
>
> The following report is specifically for libvirt on Fedora:
>
>    https://bugzilla.redhat.com/show_bug.cgi?id=874702
>
> In short, a dnsmasq instance run with the intention of listening for
> DHCP/DNS requests only on a libvirt virtual network (which is
> constructed using a Linux host bridge) would also answer queries sent
> from outside the virtualization host.
>
> This patch takes advantage of a new dnsmasq option "--bind-dynamic",
> which will cause the listening socket to be setup such that it will
> only receive those requests that actually come in via the bridge
> interface. In order for this behavior to actually occur, not only must
> "--bind-interfaces" be replaced with "--bind-dynamic", but also all
> "--listen-address" options must be replaced with a single
> "--interface" option. Fully:
>
>     --bind-interfaces --except-interface lo --listen-address x.x.x.x ...
>
> (with --listen-address possibly repeated) is replaced with:
>
>     --bind-dynamic --interface virbrX
I have some questions about this change.

1.  If I correctly understand the problem being addressed (not a given), 
a dnsmasq instance providing a dns service to a virtual network 
interface was responding to queries on other network interfaces (virtual 
or real).  Obviously (to me) this is not desired and should be 
considered a security problem.  This series of patches is intended to 
address this problem while continuing to support older versions of 
dnsmasq which do not support bind-dynamic.

[If I understand correctly then, while this is a problem for IPv4, it 
could be even more critical for IPv6.]

2.  I assume that this change still supports queries originating on the 
virtualization host and directed to the virtual network interface.

3.  I assume that dnsmasq's support of DHCP continues as before.

[I will be implementing this update and testing it over the next couple 
of days.  For one thing, I need to integrate my DHCPv6, etc. patches 
with this.  For one thing, I need to pick up the dnsmasq version 
implemented by this patch.]

4.  What about the situation where an "Internet publically available" 
service is implemented on a virtual (guest) system.  I assume that the 
dnsmasq instance for the virtual network interface will not be directly 
available for external queries.  How about if the virtualization host is 
running yet another instance of dnsmasq (not started by libvirt) which 
forwards queries to the dnsmasq instance started by libvirt (the query 
would be sent to an address on the virtual network interface).

5.  I assume dnsmasq will respond to queries on any IPv4 or IPv6 
(gateway) address defined on a virtual network interface.

6.  I assume that, if no IPv4 or IPv6 (gateway) addresses are defined on 
an interface, dnsmasq will not be started for that interface.

7.  Are there any conditions where bind-interface would still be 
preferable to bind-dynamic?  [Maybe I need to ask Simon Kelley this 
question.]

Comment:  You sure did put a lot of effort into making sure that libvirt 
would still work with older versions of dnsmasq which did not support 
bind-dynamic.

Gene