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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list