1. 30 11月, 2012 1 次提交
    • L
      network: use dnsmasq --bind-dynamic when available · 753ff83a
      Laine Stump 提交于
      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)
      753ff83a
  2. 21 10月, 2012 1 次提交
    • L
      network: always create dnsmasq hosts and addnhosts files, even if empty · 1cb1f9da
      Laine Stump 提交于
      This fixes the problem reported in:
      
        https://bugzilla.redhat.com/show_bug.cgi?id=868389
      
      Previously, the dnsmasq hosts file (used for static dhcp entries, and
      addnhosts file (used for additional dns host entries) were only
      created/referenced on the dnsmasq commandline if there was something
      to put in them at the time the network was started. Once we can update
      a network definition while it's active (which is now possible with
      virNetworkUpdate), this is no longer a valid strategy - if there were
      0 dhcp static hosts (resulting in no reference to the hosts file on the
      commandline), then one was later added, the commandline wouldn't have
      linked dnsmasq up to the file, so even though we create it, dnsmasq
      doesn't pay any attention.
      
      The solution is to just always create these files and reference them
      on the dnsmasq commandline (almost always, anyway). That way dnsmasq
      can notice when a new entry is added at runtime (a SIGHUP is sent to
      dnsmasq by virNetworkUdpate whenever a host entry is added or removed)
      
      The exception to this is that the dhcp static hosts file isn't created
      if there are no lease ranges *and* no static hosts. This is because in
      this case dnsmasq won't be setup to listen for dhcp requests anyway -
      in that case, if the count of dhcp hosts goes from 0 to 1, dnsmasq
      will need to be restarted anyway (to get it listening on the dhcp
      port). Likewise, if the dhcp hosts count goes from 1 to 0 (and there
      are no dhcp ranges) we need to restart dnsmasq so that it will stop
      listening on port 67. These special situations are handled in the
      bridge driver's networkUpdate() by checking for ((bool)
      nranges||nhosts) both before and after the update, and triggering a
      dnsmasq restart if the before and after don't match.
      1cb1f9da
  3. 07 9月, 2012 1 次提交
  4. 23 8月, 2012 1 次提交
    • G
      dnsmasq: avoid forwarding queries without a domain · f3868259
      Gene Czarcinski 提交于
      dnsmasq is forwarding a number of queries upstream that should not
      be done.  There still remains an MX query for a plain name with no
      domain specified that will be forwarded is dnsmasq has --domain=xxx
      --local=/xxx/ specified. This does not happen with no domain name
      and --local=// ... not a libvirt problem.
      
      BTW, thanks again to Claudio Bley!
      f3868259
  5. 02 2月, 2012 1 次提交
    • P
      tests: dynamically replace dnsmasq path · 22ec6000
      Philipp Hahn 提交于
      The path to the dnsmasq binary can be configured while in the test data
      the path is hard-coded to /usr/bin/. This break the test suite if a the
      binary is located in a different location, like /usr/local/sbin/.
      
      Replace the hard coded path in the test data by a token, which is
      dynamically replaced in networkxml2argvtest with the configured path
      after the test data has been loaded.
      
      (Another option would have been to modify configure.ac to generate the
       test data during configure, but I do not know of an easy way do trick
       configure into mass-generate those test files without listing every
       single one, which I consider less flexible.)
      
      - unit-test the unit-test:
        #include <assert.h>
        #define TEST(in,token,rep,out) { char *buf = strdup(in); assert(!replaceTokens(&buf, token, rep) && !strcmp(buf, out)); free(buf); }
        TEST("", "AA", "B", "");
        TEST("A", "AA", "B", "A");
        TEST("AA", "AA", "B", "B");
        TEST("AAA", "AA", "B", "BA");
        TEST("AA", "AA", "BB", "BB");
        TEST("AA", "AA", "BBB", "BBB");
        TEST("<AA", "AA", "B", "<B");
        TEST("<AA", "AA", "BB", "<BB");
        TEST("<AA", "AA", "BBB", "<BBB");
        TEST("AA>", "AA", "B", "B>");
        TEST("AA>", "AA", "BB", "BB>");
        TEST("AA>", "AA", "BBB", "BBB>");
        TEST("<AA>", "AA", "B", "<B>");
        TEST("<AA>", "AA", "BB", "<BB>");
        TEST("<AA>", "AA", "BBB", "<BBB>");
        TEST("<AA|AA>", "AA", "B", "<B|B>");
        TEST("<AA|AA>", "AA", "BB", "<BB|BB>");
        TEST("<AA|AA>", "AA", "BBB", "<BBB|BBB>");
        TEST("<AAAA>", "AA", "B", "<BB>");
        TEST("<AAAA>", "AA", "BB", "<BBBB>");
        TEST("<AAAA>", "AA", "BBB", "<BBBBBB>");
        TEST("AAAA>", "AA", "B", "BB>");
        TEST("AAAA>", "AA", "BB", "BBBB>");
        TEST("AAAA>", "AA", "BBB", "BBBBBB>");
        TEST("<AAAA", "AA", "B", "<BB");
        TEST("<AAAA", "AA", "BB", "<BBBB");
        TEST("<AAAA", "AA", "BBB", "<BBBBBB");
        alarm(1); /* no infinite loop */
        TEST("A", "A", "A", "A");
        TEST("AA", "A", "A", "AA");
        alarm(0);
      Signed-off-by: NPhilipp Hahn <hahn@univention.de>
      22ec6000
  6. 29 6月, 2011 1 次提交
    • L
      network: add domain to unqualified names defined with <host> · 25171f60
      Laine Stump 提交于
      If a domain name is defined for a network, add the --expand-hosts
      option to the dnsmasq commandline. This results in the domain being
      added to any hostname that is defined in a dns <host> element and
      contains no '.' characters (i.e. it is an "unqualified"
      hostname). Since PTR records are automatically created for any name
      defined in <host>, the result of a PTR request will change from the
      unqualified name to the qualified name.
      
      This also has the same effect on any hostnames that dnsmasq reads
      from the host's /etc/hosts file.
      
      (In the case of guest hostnames that were learned by dnsmasq via DHCP
      requests, they were already getting the domain name added on, even
      without --expand-hosts).
      25171f60
  7. 25 6月, 2011 2 次提交