[libvirt] [PATCH] Add some notes about secure usage of libvirt
Daniel P. Berrange
berrange at redhat.com
Mon Oct 14 17:06:14 UTC 2013
From: "Daniel P. Berrange" <berrange at 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 at 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
More information about the libvir-list
mailing list