[PATCH] Add some notes about secure usage of libvirt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]