[libvirt] [PATCH] Add some notes about secure usage of libvirt
From: "Daniel P. Berrange" <berrange@redhat.com> Start a page describing some of the things that applications using libvirt need to bear in mind to ensure security of their systems. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> --- docs/secureusage.html.in | 169 +++++++++++++++++++++++++++++++++++++++++++++++ docs/sitemap.html.in | 4 ++ 2 files changed, 173 insertions(+) create mode 100644 docs/secureusage.html.in diff --git a/docs/secureusage.html.in b/docs/secureusage.html.in new file mode 100644 index 0000000..998a692 --- /dev/null +++ b/docs/secureusage.html.in @@ -0,0 +1,169 @@ +<?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>Secure Usage of Libvirt</h1> + + <ul id="toc"></ul> + + <p> + This page details information that application developers and + administrators of libvirt should be aware of when working with + libvirt, that may have a bearing on security of the system. + </p> + + + <h2><a name="diskimage">Disk image handling</a></h2> + + <h3><a name="diskimageformat">Disk image format probing</a></h3> + + <p> + Historically there have been multiple flaws in QEMU and most + projects using QEMUs, related to handling of disk formats. + The problems occur when a guest is given a virtual disk backed + by raw disk format on the host. If the management application + on the host tries to auto-detect / probe the disk format, it + is vulnerable to a malicious guest which can write a qcow2 + file header into its raw disk. If the management application + subsequently probes the disk, it will see it as a 'qcow2' disk + instead of a 'raw' disk. Since 'qcow2' disks can have a copy + on write backing file, such flaw can be leveraged to read + arbitrary files on the host. The same type of flaw may occur + if the management application allows users to upload pre-created + raw images + </p> + + <p> + <strong>Recommendation:</strong> never attempt to automatically + detect the format of a disk image based on file contents which + are accessible to / originate from an untrusted source. + </p> + + <h3><a name="diskimagebacking">Disk image backing files</a></h3> + + <p> + If a management application allows users to upload pre-created + disk images in non-raw formats, it can be tricked into giving + the user access to arbitrary host files via the copy-on-write + backing file feature. This is because the qcow2 disk format + header contains a filename field which can point to any location. + It can also point to network protocols such as NBD, HTTP, GlusterFS, + RBD and more. This could allow for compromise of almost arbitrary + data accessible on the LAN/WAN. + </p> + + <p> + <strong>Recommendation:</strong> always validate that a disk + image originating from an untrusted source has no backing + file set. If a backing file is seen, reject the image. + </p> + + <h3><a name="diskimagesize">Disk image size validation</a></h3> + + <p> + If an application allows users to upload pre-created disk + images in non-raw formats, it is essential to validate the + logical disk image size, rather than the physical disk + image size. Non-raw disk images have a grow-on-demand + capability, so a user can provide a qcow2 image that may + be only 1 MB in size, but is configured to grow to many + TB in size. + </p> + + <p> + <strong>Recommendation:</strong> if receiving a non-raw disk + image from an untrusted source, validate the logical image + size stored in the disk image metadata against some finite + limit. + </p> + + <h3><a name="diskimageaccess">Disk image data access</a></h3> + + <p> + If an untrusted disk image is ever mounted on the host OS by + a management application or administrator, this opens an + avenue of attacker with which to potentially compromise the + host kernel. Filesystem drivers in OS kernels are often very + complex code and thus may have bugs lurking in them. With + Linux, there are a large number of filesystem drivers, many + of which attract little security analysis attention. Linux + will helpfull probe filesystem formats if not told to use an + explicit format, allowing an attacker the ability to target + specific weak filesystem drivers. Even commonly used and + widely audited filesystems such as <code>ext4</code> have had + <a href="https://lwn.net/Articles/538898/">bugs lurking in them</a> + undetected for years at a time. + </p> + + <p> + <strong>Recommendation:</strong> if there is a need to access + the content of a disk image, use a single-use throwaway virtual + machine to access the data. Never mount disk images on the host + OS. Ideally make use of the <a href="http://libguestfs.org">libguestfs</a> + tools and APIs for accessing disks + </p> + + <h2><a name="migration">Guest migration network</a></h2> + + <p> + Most hypervisors with support for guest migration between hosts + make use of one (or more) network connections. Typically the source + host will connect to some port on the target host to initiate the + migration. There may be separate connections for co-ordinating the + migration, transferring memory state and transferring storage. + If the network over which migration takes place is accessible the + guest, or client applications, there is potential for data leakage + via packet snooping/capture. It is also possible for a malicious + guest or client to make attempts to connect to the target host + to trigger bogus migration operations, or at least inflict a denial + of service attack. + </p> + + <p> + <strong>Recommendations:</strong> there are several things to consider + when performing migration + </p> + + <ul> + <li>Use a specific address for establishing the migration + connection which is accessible only to the virtualization + hosts themselves, not libvirt clients or virtual guests. + Most hypervisors allow the mgmt application to provide + the IP address of the target host as a way to + determine which network migration takes place on</li> + <li>Use an encrypted migration protocol. Some hypervisors + have support for encrypting the migration memory/storage + data. In other cases it can be tunnelled over the libvirtd + RPC protocol connections.</li> + <li>Use a specific address for listening for incoming migration + connections which is accessible only to the virtualization + hosts themselves, not libvirt clients or virtual guests. + Most hypervisors allow the mgmt application to configure + the IP address on which the target host listens.</li> + </ul> + + <h2><a name="storage">Storage encryption</a></h2> + + <p> + Virtual disk images will typically contain confidential data + belonging to the owner of the virtual machine. It is desirable + to protect this against data center administrators as much as + possible. For example, a rogue storage administrator may attempt + to access disk contents directly from a storage host, or a network + administrator/attack may attempt to snoop on data packets relating + to storage access. Use of disk encryption on the virtualization + host can ensure that only the virtualization host administrator + can see the plain text contents of disk images. + </p> + + <p> + <strong>Recommendation:</strong> make use of storage encryption + to protect non-local storage from attack by rogue network / + storage administrators or external attackers. This is particularly + important if the storage protocol itself does not offer any kind + of encryption capabilities. + </p> + + </body> +</html> diff --git a/docs/sitemap.html.in b/docs/sitemap.html.in index a8d2177..d821a9e 100644 --- a/docs/sitemap.html.in +++ b/docs/sitemap.html.in @@ -136,6 +136,10 @@ <a href="archnode.html">Node Devices</a> <span>Enumerating host node devices</span> </li> + <li> + <a href="secureusage.html">Secure usage</a> + <span>Secure usage of the libvirt APIs</span> + </li> </ul> </li> <li> -- 1.8.3.1
On 10/14/2013 11:06 AM, Daniel P. Berrange wrote:
From: "Daniel P. Berrange" <berrange@redhat.com>
Start a page describing some of the things that applications using libvirt need to bear in mind to ensure security of their systems.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com> --- docs/secureusage.html.in | 169 +++++++++++++++++++++++++++++++++++++++++++++++ docs/sitemap.html.in | 4 ++ 2 files changed, 173 insertions(+) create mode 100644 docs/secureusage.html.in
+ + <p> + This page details information that application developers and + administrators of libvirt should be aware of when working with + libvirt, that may have a bearing on security of the system. + </p>
Maybe worth a mention that granting someone access to the system libvirtd with the permission for writing domain XML is effectively granting them full access to the entire machine (since they can create a domain that points to an arbitrary file and use the guest to alter that file's contents). Also: while sVirt protects one guest from another, it does not protect guests from a bad admin on the host. But this could be added in a followup patch, if you wanted to get the framework in and still get a content review of new text.
+ <p> + Historically there have been multiple flaws in QEMU and most + projects using QEMUs, related to handling of disk formats.
Not sure what you meant by 'QEMUs' - maybe just 'QEMU'?
+ if the management application allows users to upload pre-created + raw images
s/$/./
+ <p> + If an untrusted disk image is ever mounted on the host OS by + a management application or administrator, this opens an + avenue of attacker with which to potentially compromise the
s/attacker/attack/
+ host kernel. Filesystem drivers in OS kernels are often very + complex code and thus may have bugs lurking in them. With + Linux, there are a large number of filesystem drivers, many + of which attract little security analysis attention. Linux + will helpfull probe filesystem formats if not told to use an
s/helpfull/helpfully/
+ <p> + <strong>Recommendations:</strong> there are several things to consider + when performing migration + </p> + + <ul> + <li>Use a specific address for establishing the migration + connection which is accessible only to the virtualization + hosts themselves, not libvirt clients or virtual guests. + Most hypervisors allow the mgmt application to provide
s/mgmt/management/
+ the IP address of the target host as a way to + determine which network migration takes place on</li> + <li>Use an encrypted migration protocol. Some hypervisors + have support for encrypting the migration memory/storage + data. In other cases it can be tunnelled over the libvirtd + RPC protocol connections.</li> + <li>Use a specific address for listening for incoming migration + connections which is accessible only to the virtualization + hosts themselves, not libvirt clients or virtual guests. + Most hypervisors allow the mgmt application to configure + the IP address on which the target host listens.</li>
Are 1 and 3 identical? More docs are always an improvement, so ACK with those issues fixed. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Mon, Oct 14, 2013 at 01:58:29PM -0600, Eric Blake wrote:
On 10/14/2013 11:06 AM, Daniel P. Berrange wrote:
From: "Daniel P. Berrange" <berrange@redhat.com>
Start a page describing some of the things that applications using libvirt need to bear in mind to ensure security of their systems.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com> --- docs/secureusage.html.in | 169 +++++++++++++++++++++++++++++++++++++++++++++++ docs/sitemap.html.in | 4 ++ 2 files changed, 173 insertions(+) create mode 100644 docs/secureusage.html.in
+ + <p> + This page details information that application developers and + administrators of libvirt should be aware of when working with + libvirt, that may have a bearing on security of the system. + </p>
Maybe worth a mention that granting someone access to the system libvirtd with the permission for writing domain XML is effectively granting them full access to the entire machine (since they can create a domain that points to an arbitrary file and use the guest to alter that file's contents). Also: while sVirt protects one guest from another, it does not protect guests from a bad admin on the host. But this could be added in a followup patch, if you wanted to get the framework in and still get a content review of new text.
Ahhh, yes, I knew there was one thing section I wanted to a write. I'll send a followup with more data.
+ <ul> + <li>Use a specific address for establishing the migration + connection which is accessible only to the virtualization + hosts themselves, not libvirt clients or virtual guests. + Most hypervisors allow the mgmt application to provide
s/mgmt/management/
+ the IP address of the target host as a way to + determine which network migration takes place on</li> + <li>Use an encrypted migration protocol. Some hypervisors + have support for encrypting the migration memory/storage + data. In other cases it can be tunnelled over the libvirtd + RPC protocol connections.</li> + <li>Use a specific address for listening for incoming migration + connections which is accessible only to the virtualization + hosts themselves, not libvirt clients or virtual guests. + Most hypervisors allow the mgmt application to configure + the IP address on which the target host listens.</li>
Are 1 and 3 identical?
One is about the connect() address for source QEMU and the other is about bind() address for dest QEMU. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
participants (2)
-
Daniel P. Berrange -
Eric Blake