- Devel - libvirt List Archives

[libvirt] [RFC PATCH 1/2] LXC: Drop capabilities only if we're not within a user namespace
by Richard Weinberger 01 Jul '13

01 Jul '13

Dropping capabilities within a user namespace makes no sense because any uid 0 process will regain all caps upon execve(). Signed-off-by: Richard Weinberger <richard(a)nod.at> --- src/lxc/lxc_container.c | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c index 958e20d..4f00420 100644 --- a/src/lxc/lxc_container.c +++ b/src/lxc/lxc_container.c @@ -1896,6 +1896,15 @@ static int lxcContainerDropCapabilities(bool keepReboot ATTRIBUTE_UNUSED) return 0; } +static int userns_supported(void) +{ + return lxcContainerAvailable(LXC_CONTAINER_FEATURE_USER) == 0; +} + +static int userns_required(virDomainDefPtr def) +{ + return def->idmap.uidmap && def->idmap.gidmap; +} /** * lxcContainerChild: @@ -1992,7 +2001,7 @@ static int lxcContainerChild(void *data) } /* drop a set of root capabilities */ - if (lxcContainerDropCapabilities(!!hasReboot) < 0) + if (!userns_required(vmDef) && lxcContainerDropCapabilities(!!hasReboot) < 0) goto cleanup; if (lxcContainerSendContinue(argv->handshakefd) < 0) { @@ -2025,16 +2034,6 @@ cleanup: return ret; } -static int userns_supported(void) -{ - return lxcContainerAvailable(LXC_CONTAINER_FEATURE_USER) == 0; -} - -static int userns_required(virDomainDefPtr def) -{ - return def->idmap.uidmap && def->idmap.gidmap; -} - virArch lxcContainerGetAlt32bitArch(virArch arch) { /* Any Linux 64bit arch which has a 32bit -- 1.8.1.4

3 27

[libvirt] [PATCH] Document security reporting & handling process
by Daniel P. Berrange 01 Jul '13

01 Jul '13

From: "Daniel P. Berrange" <berrange(a)redhat.com> Historically security issues in libvirt have been primarily triaged & fixed by the Red Hat libvirt members & Red Hat security team, who then usually notify other vendors via appropriate channels. There have been a number of times when vendors have not been properly notified ahead of announcement. It has also disadvantaged community members who have to backport fixes to releases for which there are no current libvirt stable branches. To address this, we want to make the libvirt security process entirely community focused / driven. To this end I have setup a new email address "libvirt-security(a)redhat.com" for end users to report bugs which have (possible) security implications. This email addr is backed by an invitation only, private archive, mailing list. The intent is for the list membership to comprise a subset of the libvirt core team, along with any vendor security team engineers who wish to participate in a responsible disclosure process for libvirt. Members of the list will be responsible for analysing the problem to determine if a security issue exists and then issue fixes for all current official stable branches & git master. I am proposing the following libvirt core team people as members of the security team / list (all cc'd): Daniel Berrange (Red Hat) Eric Blake (Red Hat) Jiri Denemar (Red Hat) Daniel Veillard (Red Hat) Jim Fehlig (SUSE) Doug Goldstein (Gentoo) Guido Günther (Debian) We don't have anyone from Ubuntu on the libvirt core team. Serge Hallyn is the most frequent submitter of patches from Ubuntu in recent history, so I'd like to invite him to join. Alternatively, Serge, feel free to suggest someone else to represent Ubuntu's interests. If any other vendors/distros have security people who are responsible for dealing with libvirt security issues, and want to join to get early disclosure of issues, they can suggest people. Existing security team members will vet / approve such requests to ensure they are genuine. Anyone on the team / list will be **required** to honour any embargo period agreed between members for non-public issues that are reported. The aim will be to have a maximum 2 week embargo period in the common case, extendable to 1 month if there is sufficient justification made. If anyone feels they are unable to follow such an embargo process for whatever reason, please decline membership of the security list/team. The patch which follows puts up some docs on the website about all of this.... Document how to report security bugs and the process that will be used for addressing them. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- docs/bugs.html.in | 12 +++++ docs/contact.html.in | 12 +++++ docs/securityprocess.html.in | 113 +++++++++++++++++++++++++++++++++++++++++++ docs/sitemap.html.in | 4 ++ 4 files changed, 141 insertions(+) create mode 100644 docs/securityprocess.html.in diff --git a/docs/bugs.html.in b/docs/bugs.html.in index 3d79b32..71e43e4 100644 --- a/docs/bugs.html.in +++ b/docs/bugs.html.in @@ -7,6 +7,18 @@ <ul id="toc"></ul> + <h2><a name="security">Security Issues</a></h2> + + <p> + If you think that an issue with libvirt may have security + implications, <strong>please do not</strong> publically + report it in the bug tracker, mailing lists, or irc. Libvirt + has <a href="securityprocess.html">a dedicated process for handling (potential) security issues</a> + that should be used instead. So if your issue has security + implications, ignore the rest of this page and follow the + <a href="securityprocess.html">security process</a> instead. + </p> + <h2><a name="bugzilla">Bug Tracking</a></h2> <p> diff --git a/docs/contact.html.in b/docs/contact.html.in index e34de67..51cc775 100644 --- a/docs/contact.html.in +++ b/docs/contact.html.in @@ -6,6 +6,18 @@ <ul id="toc"></ul> + <h2><a name="security">Security Issues</a></h2> + + <p> + If you think that an issue with libvirt may have security + implications, <strong>please do not</strong> publically + report it in the bug tracker, mailing lists, or irc. Libvirt + has <a href="securityprocess.html">a dedicated process for handling (potential) security issues</a> + that should be used instead. So if your issue has security + implications, ignore the rest of this page and follow the + <a href="securityprocess.html">security process</a> instead. + </p> + <h2><a name="email">Mailing lists</a></h2> <p> diff --git a/docs/securityprocess.html.in b/docs/securityprocess.html.in new file mode 100644 index 0000000..c29ae80 --- /dev/null +++ b/docs/securityprocess.html.in @@ -0,0 +1,113 @@ +<?xml version="1.0" encoding="UTF-8"?> +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> +<html xmlns="http://www.w3.org/1999/xhtml"> + <body> + + <h1>Security Process</h1> + + <ul id="toc"></ul> + + <p> + The libvirt project believes in responsible disclosure of + security problems, to allow vendors time to prepare and + distribute patches for problems ahead of their publication. + This page describes how the process works and how to report + potential security issues. + </p> + + <h2><a name="reporting">Reporting security issues</a></h2> + + <p> + In the event that a bug in libvirt is found which is + believed to have (potential) security implications there + is a dedicated contact to which a bug report / notification + should be directed. Send an email with as many details of + the problem as possible (ideally with steps to reproduce) + to the following email address: + </p> + + <pre> +<a href="mailto:libvirt-security@redhat.com">libvirt-security(a)redhat.com</a></pre> + + <p> + NB. while this email address is backed by a mailing list, it + is invitation only and moderated for non-members. As such you + will receive an auto-reply indicating the report is held for + moderation. Postings by non-members will be approved by a + moderator and the reporter copied on any replies. + </p> + + <h2><a name="seclist">Security team</a></h2> + + <p> + The libvirt security team is made up of a subset of the libvirt + core development team which covers the various distro maintainers + of libvirt, along with nominated security engineers representing + the various vendors who distribute libvirt. The team is responsible + for analysing incoming reports from users to identify whether a + security problem exists and its severity. It then works to produce + a fix for all official stable branches of libvirt and co-ordinate + embargo dates between vendors to allow simultaneous release of the + fix by all affected parties. + </p> + + <p> + If you are a security representative of a vendor distributing + libvirt and would like to join the security team, send an email + to the afore-mentioned security address. Typically an existing + member of the security team will have to vouch for your credentials + before membership is approved. All members of the security team + are <strong>required to respect the embargo policy</strong> + described below. + </p> + + <h2><a name="embargo">Publication embargo policy</a></h2> + + <p> + The libvirt security team operates a policy of + <a href="http://en.wikipedia.org/wiki/Responsible_disclosure">responsible disclosure</a>. + As such any security issue reported, that is not already publically disclosed + elswhere, will have an embargo date assigned. Members of the security team agree + not to publically disclose any details of the security issue until the embargo + date expires. + </p> + + <p> + The general aim of the team is to have embargo dates which + are two weeks or less in duration. If a problem is identified + with a proposed patch for a security issue, requiring further + investigation and bug fixing, the embargo clock may be restarted. + In exceptional circumstances longer initial embargos may be + negotiated by mutual agreement between members of the security + team and other relevant parties to the problem. Any such extended + embargoes will aim to be at most one month in duration. + </p> + + + <h2><a name="cve">CVE allocation</a></h2> + + <p> + The libvirt security team will associate each security issue with + a CVE number. The CVE numbers will usually be allocated by one of + the vendor security engineers on the security team. + </p> + + <h2><a name="branches">Branch fixing policy</a></h2> + + <p> + The libvirt community maintains one or more stable release branches + at any given point in time. The security team will aim to publish + fixes for GIT master (which will become the next major release) and + each currently maintained stable release branch. The distro maintainers + will be responsible for backporting the officially published fixes to + other release branches where applicable. + </p> + + <h2><a name="notification">Notification of issues</a></h2> + + <p> + When an embargo expires, security issues will be announced on both + the libvirt development and announcement <a href="http://libvirt.org/contact.html#email">mailing lists</a>. + </p> + </body> +</html> diff --git a/docs/sitemap.html.in b/docs/sitemap.html.in index cb7cc5b..fd10caf 100644 --- a/docs/sitemap.html.in +++ b/docs/sitemap.html.in @@ -349,6 +349,10 @@ <span>How and where to report bugs and request features</span> <ul> <li> + <a href="securityprocess.html">Security Process</a> + <span>Security bug reporting and resolution process</span> + </li> + <li> <a href="todo.html">Todo list</a> <span>Main feature request list</span> </li> -- 1.8.1.4

6 8

[libvirt] [PATCH] node device driver: update driver name during dumpxml
by Laine Stump 01 Jul '13

01 Jul '13

This fixes: https://bugzilla.redhat.com/show_bug.cgi?id=979290 https://bugzilla.redhat.com/show_bug.cgi?id=979330 The node device driver was written with the assumption that udev would use a "change" event to notify libvirt of any change to device status (including the name of the driver it was bound to). It turns out this is not the case (see Comment 4 of BZ 979290). That means that a dumpxml for a device would always show whatever driver happened to be bound at the time libvirt was started (when the node device cache was built). There was already code in the driver (for the benefit of the HAL backend) that updated the driver name from sysfs each time a device's info was retrieved from the cache. This patch just enables that manual update for the udev backend as well. --- src/node_device/node_device_driver.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/src/node_device/node_device_driver.c b/src/node_device/node_device_driver.c index 67e90a1..8e6911a 100644 --- a/src/node_device/node_device_driver.c +++ b/src/node_device/node_device_driver.c @@ -60,10 +60,15 @@ static int update_caps(virNodeDeviceObjPtr dev) } -#if defined (__linux__) && defined (WITH_HAL) -/* Under libudev changes to the driver name should be picked up as - * "change" events, so we don't call update driver name unless we're - * using the HAL backend. */ +#if defined (__linux__) && ( defined (WITH_HAL) || defined(WITH_UDEV)) +/* NB: It was previously believed that changes in driver name were + * relayed to libvirt as "change" events by udev, and the udev event + * notification is setup to recognize such events and effectively + * recreate the device entry in the cache. However, neither the kernel + * nor udev sends such an event, so it is necessary to manually update + * the driver name for a device each time its entry is used, both for + * udev *and* HAL backends. + */ static int update_driver_name(virNodeDeviceObjPtr dev) { char *driver_link = NULL; -- 1.7.11.7

2 2

[libvirt] [PATCH] pci: initialize virtual_functions array pointer to avoid segfault
by Laine Stump 01 Jul '13

01 Jul '13

This fixes https://bugzilla.redhat.com/show_bug.cgi?id=971325 The problem was that if virPCIGetVirtualFunctions was given the name of a non-existent interface, it would return to its caller without initializing the pointer to the array of virtual functions to NULL, and the caller (virNetDevGetVirtualFunctions) would try to VIR_FREE() the invalid pointer. The final error message before the crash would be: virPCIGetVirtualFunctions:2088 : Failed to open dir '/sys/class/net/eth2/device': No such file or directory In this patch I move the initialization in virPCIGetVirtualFunctions() to the begining of the function, and also do an explicit initialization in virNetDevGetVirtualFunctions, just in case someone in the future adds code into that function prior to the call to virPCIGetVirtualFunctions. --- src/util/virnetdev.c | 3 +++ src/util/virpci.c | 5 +++-- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/src/util/virnetdev.c b/src/util/virnetdev.c index ebe20d0..5e8dffb 100644 --- a/src/util/virnetdev.c +++ b/src/util/virnetdev.c @@ -1100,6 +1100,9 @@ virNetDevGetVirtualFunctions(const char *pfname, char *pci_sysfs_device_link = NULL; char *pciConfigAddr = NULL; + *virt_fns = NULL; + *n_vfname = 0; + if (virNetDevSysfsFile(&pf_sysfs_device_link, pfname, "device") < 0) return ret; diff --git a/src/util/virpci.c b/src/util/virpci.c index 2acab1a..15de3f9 100644 --- a/src/util/virpci.c +++ b/src/util/virpci.c @@ -2449,6 +2449,9 @@ virPCIGetVirtualFunctions(const char *sysfs_path, VIR_DEBUG("Attempting to get SR IOV virtual functions for device" "with sysfs path '%s'", sysfs_path); + *virtual_functions = NULL; + *num_virtual_functions = 0; + dir = opendir(sysfs_path); if (dir == NULL) { memset(errbuf, '\0', sizeof(errbuf)); @@ -2458,8 +2461,6 @@ virPCIGetVirtualFunctions(const char *sysfs_path, return ret; } - *virtual_functions = NULL; - *num_virtual_functions = 0; while ((entry = readdir(dir))) { if (STRPREFIX(entry->d_name, "virtfn")) { virPCIDeviceAddress *config_addr = NULL; -- 1.7.11.7

2 2

[libvirt] [PATCH] spec: require xen-devel for libxl driver
by Eric Blake 30 Jun '13

30 Jun '13

When using 'rpmbuild --define "_without_xen"', but on a new enough Fedora where %{with_libxl} still gets set to 1 by default, the build dependencies were incomplete, which could result in 'make rpm' failing because ./configure failed to build the libxl driver. * libvirt.spec.in (BuildRequires): Fix xen-devel condition. Signed-off-by: Eric Blake <eblake(a)redhat.com> --- Pushing under the build-breaker rule. I found this on a machine with 'xen-devel' uninstalled, while running ./autobuild.sh; it took me a while to find the root cause, since autobuild.sh uses 'rpmbuild --nodeps' and therefore failed to tell me which packages I did not have installed. libvirt.spec.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index f40b614..aee61fa 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -412,7 +412,7 @@ BuildRequires: python-devel %if %{with_systemd} BuildRequires: systemd-units %endif -%if %{with_xen} +%if %{with_xen} || %{with_libxl} BuildRequires: xen-devel %endif BuildRequires: libxml2-devel -- 1.8.1.4

1 0

[libvirt] [PATCH 0/4] Resolve some recent Valgrind errors
by John Ferlan 29 Jun '13

29 Jun '13

Ran Valgrind today and found, investigated, and resolved the errors seen. John Ferlan (4): Resolve valgrind error in virNetDevVlanParse() Resolve valgrind error in virStorageBackendCreateQemuImgCmd() Resolve valgrind error in remoteConfigGetStringList() Resolve valgrind errors for nodedev cap parsing daemon/libvirtd-config.c | 6 ++++++ src/conf/netdev_vlan_conf.c | 24 +++++++++++++----------- src/conf/node_device_conf.c | 3 +++ src/storage/storage_backend.c | 4 +++- 4 files changed, 25 insertions(+), 12 deletions(-) -- 1.8.1.4

2 9

[libvirt] [PATCH] doc: Fix reference to #elementsUSB
by Philipp Hahn 29 Jun '13

29 Jun '13

aae0fc2a922b3e31dae7648c547fca2ac2587625 removed the #elementsUSB anchor but did not update the links to point to the new section #elementsHostDev. Signed-off-by: Philipp Hahn <hahn(a)univention.de> --- docs/formatdomain.html.in | 2 +- docs/formatnode.html.in | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index d651816..cc4c5ea 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -146,7 +146,7 @@ configure in the desired way, which is why per-device boot elements (see <a href="#elementsDisks">disks</a>, <a href="#elementsNICS">network interfaces</a>, and - <a href="#elementsUSB">USB and PCI devices</a> sections below) were + <a href="#elementsHostDev">USB and PCI devices</a> sections below) were introduced and they are the preferred way providing full control over booting order. The <code>boot</code> element and per-device boot elements are mutually exclusive. <span class="since">Since 0.1.3, diff --git a/docs/formatnode.html.in b/docs/formatnode.html.in index ad05a70..5f57a5a 100644 --- a/docs/formatnode.html.in +++ b/docs/formatnode.html.in @@ -13,7 +13,7 @@ prefix <code>virNodeDevice</code>, which deal with management of host devices that can be handed to guests via passthrough as <hostdev> elements - in <a href="formatdomain.html#elementsUSB">the domain XML</a>. + in <a href="formatdomain.html#elementsHostDev">the domain XML</a>. These devices are represented as a hierarchy, where a device on a bus has a parent of the bus controller device; the root of the hierarchy is the node named "computer". -- 1.7.10.4

2 1

[libvirt] Entering freeze for libvirt-1.1.0
by Daniel Veillard 28 Jun '13

28 Jun '13

Since Dan pushed the fine grained ACL control patches, this release really ought to be 1.1.0, I just tagged it in git and pushed tarball and rpms to the server: ftp://libvirt.org/libvirt/ I know that Laine has still a patch set to push, now it seems they all got ACK'ed so better get them in for rc2, which I will probably push on thursday. Then if everything looks fine we can have the final release on Monday. I gave it my usual user test, on Fedora, seems to work fine from my limited perspective. I just had to push the attached patch as a build breaker otherwise make rpm would wail because the polkit API definitions would not be packaged. Probably worth a double checking by Dan for correctness. Thanks in advance for feedback on the candidate release, Daniel -- Daniel Veillard | Open Source and Standards, Red Hat veillard(a)redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/

6 9

[libvirt] Bug 979411 - virsh migration copy-storage-all fails with "Unable to read from monitor: Connection reset by peer"
by chandrashekar shastri 28 Jun '13

28 Jun '13

Hi, I have filed a bug for virsh migration copy-storage-all: Bug 979411 - virsh migration copy-storage-all fails with "Unable to read from monitor: Connection reset by peer" Earlier I had filed this bug in launched: Bug #1192499 : virsh migration copy-storage-all fails with "Unable to read from monitor: Connection reset by peer" Thanks, Chandrashekar Shastri

1 0

[libvirt] [PATCH] add support for libssh2 password from auth file
by David Maciejak 28 Jun '13

28 Jun '13

Hi, I was discussing with Daniel about the best way to pass the ssh password when using such kind of uri: 'xen+libssh2:// root(a)192.168.0.10?sshauth=password' As it seems passing the password in the uri is not a good option, maybe we can grab it from auth conf ? it seems it's not the case as now (tell me if i am wrong). So enclosed a patch to add this feature. As you can see in virnetclient.c there is no virAuthGetPassword call, so the authfile is never used. The patch enclosed is modifying the function prototype to add virConnectPtr parameter (so remote_driver.c virNetClientNewLibSSH2 call has to be updated too and the corresponding .h too). Once we have access to virConnectPtr, as you will see in the patch we can check if authMethods is set to 'password' and grab the password from auth file by calling virAuthGetPassword. regards, david

4 11