Re: [libvirt] [PATCH 0/3] network: resolve CVE 2012-3411
On 11/21/2012 09:55 PM, Laine Stump wrote: This patch series resolves the libvirt part of CVE 2012-3411: https://bugzilla.redhat.com/show_bug.cgi?id=833033 Further details are in PATCH 3/3. Things are going well and I have the DHCPv6 patches re-worked to be on top of these patches. I am using the new capabilities to get the dnsmasq version. I had to add driver being a parameter passed to networkStartRadvd() so that I could check for the dnsmasq version. I also changed a couple of your tests to have dnsmasq version 2.64 rather than 2.63 so that I could check for the DHCPv6 behavior. Now, on the conf-file which should not be too bad. It is so much fun when two or more people are changing the same source code at the same time ;}} Gene -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Is DBus a hard dependency
Hi,
currently running libvirtd without DBus fails due to:
error : nwfilterDriverStartup:208 : DBus matches could not be installed.
Disabling nwfilter driver
error : virDBusGetSystemBus:77 : internal error Unable to get DBus system bus
connection: Failed to connect to socket /var/run/dbus/system_bus_socket: No
such file or directory
error : virStateInitialize:810 : Initialization of NWFilter state driver failed
error : daemonRunStateInit:784 : Driver state initialization failed
because we fail driver initialization hard in nwfilter_driver.c:
if (nwfilterDriverInstallDBusMatches(sysbus) 0) {
VIR_ERROR(_(DBus matches could not be installed. Disabling nwfilter
driver));
/*
* unfortunately this is fatal since virNWFilterTechDriversInit
* may have caused the ebiptables driver to use the firewall tool
* but now that the watches don't work, we just disable the nwfilter
* driver
*/
goto error;
}
I wonder if this on prupose or if we can just make this a soft error and
go on without DBus? At least in the !HAVE_FIREWALLD case it should be
o.k. to continue. Shouldn't it? See attached patch.
Cheers,
-- Guido
From 22571860568bfe8026e60dcede8f332ec6fd002f Mon Sep 17 00:00:00 2001
Message-Id: 22571860568bfe8026e60dcede8f332ec6fd002f.1353774807.git@sigxcpu.org
From: =?UTF-8?q?Guido=20G=C3=BCnther?= a...@sigxcpu.org
Date: Sat, 24 Nov 2012 17:32:59 +0100
Subject: [PATCH] nwfilter: Allow DBus initialization to fail
To: libvir-list@redhat.com
in case we don't use firewalld. This allows us to run without
DBus on servers.
---
src/nwfilter/nwfilter_driver.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/src/nwfilter/nwfilter_driver.c b/src/nwfilter/nwfilter_driver.c
index 12f47ef..e4f6ec9 100644
--- a/src/nwfilter/nwfilter_driver.c
+++ b/src/nwfilter/nwfilter_driver.c
@@ -204,6 +204,7 @@ nwfilterDriverStartup(int privileged)
* initializing
*/
if (nwfilterDriverInstallDBusMatches(sysbus) 0) {
+#if HAVE_FIREWALLD
VIR_ERROR(_(DBus matches could not be installed. Disabling nwfilter
driver));
/*
@@ -213,6 +214,7 @@ nwfilterDriverStartup(int privileged)
* driver
*/
goto error;
+#endif
}
if (privileged) {
--
1.7.10.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Proposal: no dnsmasq (no dhcp and no dns) and no radvd option
On 11/23/2012 02:18 PM, Gene Czarcinski wrote: On 11/20/2012 05:29 PM, Laine Stump wrote: On 11/20/2012 02:36 PM, Gene Czarcinski wrote: Laine mentioned something yesterday that got me to thinking: being able to specify that dnsmasq is not to be started for an interface. Let me expand that by saying that libvirt would not start dnsmasq for either dns or dhcp and also would not start radvd. However, the IPv4 and IPv6 gateway addresses would be defined on the virtual network interface and the usual iptables and ip6tables rules would be in force. This would allow a user to configure dnsmasq to meet any user desires or use something completely different instead of dnsmasq. Questions: Useful? Worth the time and effort? That was already determined before I mentioned it to you - it's been requested several times, and I've told some people it was going to happen, although didn't say when:-). OK, color this almost done (doc and schemas need updating). Three new parameters are added: network disableDnsmasq='yes' logDnsQueries='yes' logDhcp='yes' Don't refer to dnsmasq specifically in the XML unless it's something that is unique to dnsmasq (and then we should seriously consider if we're thinking about it the right way before adding it). The intent is that the XML should describe the desired configuration in a manner high level enough that a new driver using different backend components would be able to use the same XML attributes and arrive at similar functionality. For example, there is active work right now to support libvirt's server side on FreeBSD, and they may decide that they want to implement their networks using different implementations of DNS and dhcp servers (they will already need to do something different in place of Linux host brdges and iptables, so it will have to be a completely new driver anyway). Obviously there are cases where something specific to the backend needs to be in the XML; for example the virtio-net drivers can specify driver name='qemu' ... and in that case can have an option ioeventfd and event_idx options which would probably be meaningless to any netdev driver for another hypervisor, but we aim to keep that to a minimum, and use it only when the characteristic described really is unique to particular backend). (At any rate, it seems reasonable to me that someone may want us to provide a dhcp server but no dns server. Yes, this also implies that we should have a way in the config to feed in the address of an alternative DNS server (--dhcp-option=option:dns-server,x.x.x.x and --dhcp-option=option6:dnsserver,::) to send to dhcp clients when they've disabled dnsmasq's own dns server (in case you hadn't found it in the manpage yet - you can run dnsmasq with no dns server by adding --port=0 to the commandline). As soon as I hit send on this, I'm going to type up a short mail asking for comments on how to add support for any standard dhcp option. As for the other two - any reason why you used logDnsQueries instead of logDns? Also, do you think we might want the ability to specify a level in the future? (I guess if we did, that could coexist with yes|no). And while we're on the topic of logging: one thing that's bothered me a lot, and we've had other people complain about it as well, is that every single DHCP lease renewal results in a message to /var/log/messages, and there doesn't seem to be any way to suppress it. Is that correct? If nothing is specified, then the default is no, no, no so that things work as they do now. Currently, if the boolean value is 'no' or false, then that parameter is not written out. I could easily change that depending on what others want to do. Laine, I changed this to be disableDnsmasq because that is the real result. If this is specified, then starting radvd will also be suppressed. It is as if no IPv4 or IPv6 addresses were specified. However, the iptables and ip6tables rules will remain the same since it is assumed that gateway addresses will be specified. Actually that's yet another switch that we need to add - the ability to suppress all iptables rules for a particular network (unless it is in NAT mode, in which case it makes no sense, because it's the difference in rules that changes it from mode='route' to mode='nat'). Perhaps it could be something like filter='none|open|restricted', although I don't know if that's descriptive enough - even without getting into specific protocols (which I don't think should be done - at that point they should really be using a guest-specific filterref) you might still want to know if there should be any rules at all, allow everything, allow outgoing sessions but not incoming, allow inter-guest traffic but not incoming from the outside, allow nothing (all of these could be overridden by a particular guest's filterref) I have scratched an itch of mine by providing a way to specify that dns-queries and dhcp activity should be logged and that this is
[libvirt] RFC: adding configuration for standard dhcp options to network
There have been multiple requests over the last couple years to make the DHCP server of libvirt's virutal networks more configurable (for example, see the following BZ: https://bugzilla.redhat.com/show_bug.cgi?id=824573 ). You can see a full list of the options supported by dnsmasq with this command: dnsmasq --help dhcp The biggest question here is in exactly how to represent the options in the network XML. I can see a few different options, among them: 1) make each option its own element within dhcp, e.g.: dnsServer family='ipv4' address='x.x.x.x'/ dnsServer family='ipv6' address=':::1'/ ntpServer address='y.y.y.y'/ smtpServer address='z.z.z.z'/ 2) A variation of (1) where each option could appear only once, but with two attributes, one for ipv6 address and one for ipv4: dnsServer address4='x.x.x.x'address6=':::1'/ ntpServer address4='y.y.y.y'/ 3) have a repeatable option element (again, a subelement of dhcp that can contain any number of the options as attributes: option family='ipv4' dnsServer='x.x.x.x' ntpServer='y.y.y.y' smtpServer='z.z.z.z'/ option family='ipv6' dnsServer='::1'/ (in this case, we may or may not support repeating option to add more options for the same family). 4) yet another variation, where each option is a subelement of option family='': option family='ipv4' dnsServerx.x.x.x/dnsServer ntpServery.y.y.y/ntpServer smtpServerz.z.z.z/smtpServer /option option family='ipv6' dnsServer:::1/dnsServer /option I'm not sure which of these would be more straightforward for a user. One thought I've had is that dnsmasq at least allows specifying different groups of guest addresses (with a tag) and applying different options to addresses with different tags. I don't know if we'll ever use that capability, but if we do it *seems* like any of these methods could be adapted to specifying multiple groups. Does anyone have a preference? (I have a narrow preference for (1), simply because it was the first to come to my mind, but could easily be swayed to one of the others, or something else, given a logical reason). -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] storage: fix logical volume cloning
Commit 258e06c removed setting of the volume type to
VIR_STORAGE_VOL_BLOCK, which leads to failures in
storageVolumeCreateXMLFrom.
The type (and target.format) of the volume was set to zero. In
virStorageBackendGetBuildVolFromFunction, this gets interpreted as
VIR_STORAGE_FILE_NONE and the qemu-img tool is called with unknown
none format.
Bug: https://bugzilla.redhat.com/show_bug.cgi?id=879780
---
src/storage/storage_backend_logical.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/src/storage/storage_backend_logical.c
b/src/storage/storage_backend_logical.c
index de43c3a..fd5cbd1 100644
--- a/src/storage/storage_backend_logical.c
+++ b/src/storage/storage_backend_logical.c
@@ -708,6 +708,8 @@ virStorageBackendLogicalCreateVol(virConnectPtr conn,
return -1;
}
+vol-type = VIR_STORAGE_VOL_BLOCK;
+
if (vol-target.path != NULL) {
/* A target path passed to CreateVol has no meaning */
VIR_FREE(vol-target.path);
--
1.7.8.6
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 3/3] network: use dnsmasq --bind-dynamic when available
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
