11:19 p.m.
On 11/23/2012 07:44 AM, Gene Czarcinski wrote:
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).
To be more precise, it was responding to DNS queries sent to the proper
IP address, but arriving on the socket via a different interface than
the bridge of the virtual network.
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.
Correct.
[If I understand correctly then, while this is a problem for IPv4, it
could be even more critical for IPv6.]
What makes it 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.
Interesting question. I hadn't tried it. Is there a specific scenario
where you use this (I can think of one - perhaps the system dns server
wants to have access to the A and PTR records for guests so that the
host (and possibly external entities) can reference them by name... Ah,
I see you mention that down in item 4).
3. I assume that dnsmasq's support of DHCP continues as before.
Since libvirt's dnsmasq didn't previously answer requests on other
interfaces, I'm fairly certain that this change, which further limits
the scope of request sources, won't affect dhcp, but of course only a
good round of testing will prove that out :-)
[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).
That's definitely something I need to try before pushing...
Okay, I just tried it and it works (although the packets show up on lo
rather than the bridge). This is the same behavior as previously.
5. I assume dnsmasq will respond to queries on any IPv4 or IPv6
(gateway) address defined on a virtual network interface.
Correct. As long as it arrives at the listening socket via the bridge
interface for that network.
6. I assume that, if no IPv4 or IPv6 (gateway) addresses are defined
on an interface, dnsmasq will not be started for that interface.
Correct. That's always been the case, and doesn't change now.
7. Are there any conditions where bind-interface would still be
preferable to bind-dynamic? [Maybe I need to ask Simon Kelley this
question.]
I notice that you asked him on dnsmasq-discuss, and his answer was (as
far as I understood) "no".
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.
The first rule of libvirt club is to not needlessly break existing
installations :-) (seriously though, we can't be sure how long it would
be until other distros get a new enough dnsmasq, and we can't break
libvirt for all those people in the interim). Whenever something is
added to libvirt, we're not only thinking of compatibility with running
a new libvirt on a system with older binaries from other packages, but
also running a new libvirt client side to connect to an older libvirt
server side, old client to new server, saving a guest under an old
libvirt and restoring under a new libvirt, saving under new libvirt and
restoring under old (sometimes this just can't be made to work),
migrating a guest from a system with old libvirt to new, migrating in
the opposite direction (again, sometimes this simply cannot work)...
those are just the things that come to mind.