External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2025-01-08 14:05:19 +00:00
Code Issues Packages Projects Releases Wiki Activity
6b3edda207
libvirt/tests/networkxml2argvdata/nat-network.argv

8 lines
334 B
Plaintext
Raw Normal View History

network: use dnsmasq --bind-dynamic when available 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 Of course libvirt can't use this new option if the host's dnsmasq doesn't have it, but we still want libvirt to function (because the great majority of libvirt installations, which only have mode='nat' networks using RFC1918 private address ranges (e.g. 192.168.122.0/24), are immune to this vulnerability from anywhere beyond the local subnet of the host), so we use the new dnsmasqCaps API to check if dnsmasq supports the new option and, if not, we use the "old" option style instead. In order to assure that this permissiveness doesn't lead to a vulnerable system, we do check for non-private addresses in this case, and refuse to start the network if both a) we are using the old-style options, and b) the network has a publicly routable IP address. Hopefully this will provide the proper balance of not being disruptive to those not practically affected, and making sure that those who *are* affected get their dnsmasq upgraded. (--bind-dynamic was added to dnsmasq in upstream commit 54dd393f3938fc0c19088fbd319b95e37d81a2b0, which was included in dnsmasq-2.63) (cherry picked from commit 753ff83a50263d6975f88d6605d4b5ddfcc97560) Conflicts: src/network/bridge_driver.c * needed to change virReportError() to the older networkReportError() tests/networkxml2argvdata/nat-network-dns-txt-record.argv * this test file has an example of an arg with embedded space, which gets sorrounded by '' in newer releases. Other items on the same line had been modified. tests/networkxml2argvdata/routed-network.argv * in the newer releases, this test file had an --addn-hosts arg that didn't exist on this branch. Again, it was in the surrounding context of the changes that had been made on master.
2012-11-22 02:21:02 +00:00
@DNSMASQ@ --strict-order \
remove dnsmasq command line parameter "--filterwin2k" This patch removed the "--filterwin2k" dnsmasq command line parameter which was unnecessary for domain specification, possibly blocked some usage, and was command line clutter. Gene Czarcinski <gene@czarc.net> (cherry picked from commit f20b7dbe633acf7df9921027c6ca4f0b97918c8c) Conflicts: tests/networkxml2argvdata/nat-network-dns-txt-record.argv
2012-09-06 16:08:22 +00:00
--local=// --domain-needed --conf-file= \
network: prevent dnsmasq from listening on localhost This patch resolves the problem reported in: https://bugzilla.redhat.com/show_bug.cgi?id=886663 The source of the problem was the fix for CVE 2011-3411: https://bugzilla.redhat.com/show_bug.cgi?id=833033 which was originally committed upstream in commit 753ff83a50263d6975f88d6605d4b5ddfcc97560. That commit improperly removed the "--except-interface lo" from dnsmasq commandlines when --bind-dynamic was used (based on comments in the latter bug). It turns out that the problem reported in the CVE could be eliminated without removing "--except-interface lo", and removing it actually caused each instance of dnsmasq to listen on localhost on port 53, which created a new problem: If another instance of dnsmasq using "bind-interfaces" (instead of "bind-dynamic") had already been started (or if another instance started later used "bind-dynamic"), this wouldn't have any immediately visible ill effects, but if you tried to start another dnsmasq instance using "bind-interfaces" *after* starting any libvirt networks, the new dnsmasq would fail to start, because there was already another process listening on port 53. This patch changes the network driver to *always* add "except-interface=lo" to dnsmasq conf files, regardless of whether we use bind-dynamic or bind-interfaces. This way no libvirt dnsmasq instances are listening on localhost (and the CVE is still fixed). The actual code change is miniscule, but must be propogated through all of the test files as well. (This is *not* a cherry-pick of the upstream commit that fixes the bug (commit d66eb7866757dd371560c288dc6201fb9348792a), because subsequent to the CVE fix, another patch changed the network driver to put dnsmasq options in a conf file rather than directly on the dnsmasq commandline preserving the same options), so a cherry-pick is just one very large conflict.)
2012-12-13 06:46:40 +00:00
--except-interface lo --bind-dynamic --interface virbr0 \
build: avoid long line tests 'make syntax-check' regression introduced in commit 60b9c69. * tests/networkxml2argvdata/*.argv: Break long lines.
2011-06-24 21:30:00 +00:00
--dhcp-range 192.168.122.2,192.168.122.254 \
--dhcp-leasefile=/var/lib/libvirt/dnsmasq/default.leases \
network: Fix dnsmasq hostsfile creation logic and related tests networkSaveDnsmasqHostsfile was added in 8fa9c2214247 (Apr 2010). It has a force flag. If the dnsmasq hostsfile already exists force needs to be true to overwrite it. networkBuildDnsmasqArgv sets force to false, networkDefine sets it to true. This results in the hostsfile being written only in networkDefine in the common case. If no error occurred networkSaveDnsmasqHostsfile returns true and networkBuildDnsmasqArgv adds the --dhcp-hostsfile to the dnsmasq command line. networkSaveDnsmasqHostsfile was changed in 89ae9849f744 (24 Jun 2011) to return a new dnsmasqContext instead of reusing one. This change broke the logic of the force flag as now networkSaveDnsmasqHostsfile returns NULL on error, but the early return -- if force was not set and the hostsfile exists -- returns 0. This turned the early return in an error case and networkBuildDnsmasqArgv didn't add the --dhcp-hostsfile option anymore if the hostsfile already exists. It did because networkDefine created the hostsfile already. Then 9d4e2845d498 fixed the return 0 case in networkSaveDnsmasqHostsfile but didn't apply the force option correctly to the new addnhosts file. Now force doesn't control an early return anymore, but influences the handling of the hostsfile context creation and dnsmasqSave is always called now. This commit also added test cases that reveal several problems. First, the tests now calls functions that try to write the dnsmasq config files to disk. If someone runs this tests as root this might overwrite actively used dnsmasq config files, this is a no-go. Also the tests depend on configure --localstatedir, this needs to be fixed as well, because it makes the tests fail when localstatedir is different from /var. This patch does several things to fix this: 1) Move dnsmasqContext creation and saving out of networkBuildDnsmasqArgv to the caller to separate the command line generation from the config file writing. This makes the command line generation testable without the risk of interfering with system files, because the tests just don't call dnsmasqSave. 2) This refactoring of networkSaveDnsmasqHostsfile makes the force flag useless as the saving happens somewhere else now. This fixes the wrong usage of the force flag in combination with then newly added addnhosts file by removing the force flag. 3) Adapt the wrong test cases to the correct behavior, by adding the missing --dhcp-hostsfile option. Both affected tests contain DHCP host elements but missed the necessary --dhcp-hostsfile option. 4) Rename networkSaveDnsmasqHostsfile to networkBuildDnsmasqHostsfile, because it doesn't save the dnsmasqContext anymore. 5) Move all directory creations in dnsmasq context handling code from the *New functions to dnsmasqSave to avoid directory creations in system paths in the test cases. 6) Now that networkBuildDnsmasqArgv doesn't create the dnsmasqContext anymore the test case can create one with the localstatedir that is expected by the tests instead of the configure --localstatedir given one.
2011-06-28 11:07:59 +00:00
--dhcp-lease-max=253 --dhcp-no-override \
--dhcp-hostsfile=/var/lib/libvirt/dnsmasq/default.hostsfile\
Reference in New Issue Copy Permalink