From: "Daniel P. Berrange" <berrange@xxxxxxxxxx> 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@xxxxxxxxxx> --- 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list