docs/secureusage.html

   1 <?xml version="1.0" encoding="UTF-8"?>
   2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
   3 <html xmlns="http://www.w3.org/1999/xhtml">
   4 <!--
   5         This file is autogenerated from secureusage.html.in
   6         Do not edit this file. Changes will be lost.
   7       -->
   8   <head>
   9     <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  10     <link rel="stylesheet" type="text/css" href="main.css" />
  11     <link rel="SHORTCUT ICON" href="32favicon.png" />
  12     <title>libvirt: Secure Usage of Libvirt</title>
  13     <meta name="description" content="libvirt, virtualization, virtualization API" />
  14   </head>
  15   <body>
  16     <div id="header">
  17       <div id="headerLogo"></div>
  18       <div id="headerSearch">
  19         <form action="search.php" enctype="application/x-www-form-urlencoded" method="get"><div>
  20             <input id="query" name="query" type="text" size="12" value="" />
  21             <input id="submit" name="submit" type="submit" value="Search" />
  22           </div></form>
  23       </div>
  24     </div>
  25     <div id="body">
  26       <div id="menu">
  27         <ul class="l0"><li>
  28             <div>
  29               <a title="Front page of the libvirt website" class="inactive" href="index.html">Home</a>
  30             </div>
  31           </li><li>
  32             <div>
  33               <a title="Details of new features and bugs fixed in each release" class="inactive" href="news.html">News</a>
  34             </div>
  35           </li><li>
  36             <div>
  37               <a title="Applications known to use libvirt" class="inactive" href="apps.html">Applications</a>
  38             </div>
  39           </li><li>
  40             <div>
  41               <a title="Get the latest source releases, binary builds and get access to the source repository" class="inactive" href="downloads.html">Downloads</a>
  42             </div>
  43           </li><li>
  44             <div>
  45               <a title="Information for users, administrators and developers" class="active" href="docs.html">Documentation</a>
  46               <ul class="l1"><li>
  47                   <div>
  48                     <a title="How to compile libvirt" class="inactive" href="compiling.html">Compiling</a>
  49                   </div>
  50                 </li><li>
  51                   <div>
  52                     <a title="Information about deploying and using libvirt" class="inactive" href="deployment.html">Deployment</a>
  53                   </div>
  54                 </li><li>
  55                   <div>
  56                     <a title="Overview of the logical subsystems in the libvirt API" class="active" href="intro.html">Architecture</a>
  57                     <ul class="l2"><li>
  58                         <div>
  59                           <a title="Terminology and goals of libvirt API" class="inactive" href="goals.html">Goals</a>
  60                         </div>
  61                       </li><li>
  62                         <div>
  63                           <a title="The libvirt API concepts" class="inactive" href="api.html">API concepts</a>
  64                         </div>
  65                       </li><li>
  66                         <div>
  67                           <a title="Managing virtual machines" class="inactive" href="archdomain.html">Domains</a>
  68                         </div>
  69                       </li><li>
  70                         <div>
  71                           <a title="Providing isolated networks and NAT based network connectivity" class="inactive" href="archnetwork.html">Network</a>
  72                         </div>
  73                       </li><li>
  74                         <div>
  75                           <a title="Managing storage pools and volumes" class="inactive" href="archstorage.html">Storage</a>
  76                         </div>
  77                       </li><li>
  78                         <div>
  79                           <a title="Enumerating host node devices" class="inactive" href="archnode.html">Node Devices</a>
  80                         </div>
  81                       </li><li>
  82                         <div>
  83                           <span class="active">Secure usage</span>
  84                         </div>
  85                       </li></ul>
  86                   </div>
  87                 </li><li>
  88                   <div>
  89                     <a title="Description of the XML formats used in libvirt" class="inactive" href="format.html">XML format</a>
  90                   </div>
  91                 </li><li>
  92                   <div>
  93                     <a title="Hypervisor specific driver information" class="inactive" href="drivers.html">Drivers</a>
  94                   </div>
  95                 </li><li>
  96                   <div>
  97                     <a title="Reference manual for the C public API" class="inactive" href="html/index.html">API reference</a>
  98                   </div>
  99                 </li><li>
 100                   <div>
 101                     <a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
 102                   </div>
 103                 </li><li>
 104                   <div>
 105                     <a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
 106                   </div>
 107                 </li><li>
 108                   <div>
 109                     <a title="A guide and reference for developing with libvirt" class="inactive" href="devguide.html">Development Guide</a>
 110                   </div>
 111                 </li><li>
 112                   <div>
 113                     <a title="Command reference for virsh" class="inactive" href="virshcmdref.html">Virsh Commands</a>
 114                   </div>
 115                 </li><li>
 116                   <div>
 117                     <a title="Project governance and code of conduct" class="inactive" href="governance.html">Governance</a>
 118                   </div>
 119                 </li></ul>
 120             </div>
 121           </li><li>
 122             <div>
 123               <a title="User contributed content" class="inactive" href="http://wiki.libvirt.org">Wiki</a>
 124             </div>
 125           </li><li>
 126             <div>
 127               <a title="Frequently asked questions" class="inactive" href="http://wiki.libvirt.org/page/FAQ">FAQ</a>
 128             </div>
 129           </li><li>
 130             <div>
 131               <a title="How and where to report bugs and request features" class="inactive" href="bugs.html">Bug reports</a>
 132             </div>
 133           </li><li>
 134             <div>
 135               <a title="How to contact the developers via email and IRC" class="inactive" href="contact.html">Contact</a>
 136             </div>
 137           </li><li>
 138             <div>
 139               <a title="Available test suites for libvirt" class="inactive" href="testsuites.html">Test suites</a>
 140             </div>
 141           </li><li>
 142             <div>
 143               <a title="Miscellaneous links of interest related to libvirt" class="inactive" href="relatedlinks.html">Related Links</a>
 144             </div>
 145           </li><li>
 146             <div>
 147               <a title="Overview of all content on the website" class="inactive" href="sitemap.html">Sitemap</a>
 148             </div>
 149           </li></ul>
 150       </div>
 151       <div id="content">
 152         <h1>Secure Usage of Libvirt</h1>
 153         <ul><li>
 154             <a href="#diskimage">Disk image handling</a>
 155             <ul><li>
 156                 <a href="#diskimageformat">Disk image format probing</a>
 157               </li><li>
 158                 <a href="#diskimagebacking">Disk image backing files</a>
 159               </li><li>
 160                 <a href="#diskimagesize">Disk image size validation</a>
 161               </li><li>
 162                 <a href="#diskimageaccess">Disk image data access</a>
 163               </li></ul>
 164           </li><li>
 165             <a href="#migration">Guest migration network</a>
 166           </li><li>
 167             <a href="#storage">Storage encryption</a>
 168           </li></ul>
 169         <p>
 170       This page details information that application developers and
 171       administrators of libvirt should be aware of when working with
 172       libvirt, that may have a bearing on security of the system.
 173     </p>
 174         <h2>
 175           <a name="diskimage" shape="rect" id="diskimage">Disk image handling</a>
 176           <a class="headerlink" href="#diskimage" title="Permalink to this headline">¶</a>
 177         </h2>
 178         <h3>
 179           <a name="diskimageformat" shape="rect" id="diskimageformat">Disk image format probing</a>
 180           <a class="headerlink" href="#diskimageformat" title="Permalink to this headline">¶</a>
 181         </h3>
 182         <p>
 183       Historically there have been multiple flaws in QEMU and most
 184       projects using QEMU, related to handling of disk formats.
 185       The problems occur when a guest is given a virtual disk backed
 186       by raw disk format on the host. If the management application
 187       on the host tries to auto-detect / probe the disk format, it
 188       is vulnerable to a malicious guest which can write a qcow2
 189       file header into its raw disk. If the management application
 190       subsequently probes the disk, it will see it as a 'qcow2' disk
 191       instead of a 'raw' disk. Since 'qcow2' disks can have a copy
 192       on write backing file, such flaw can be leveraged to read
 193       arbitrary files on the host. The same type of flaw may occur
 194       if the management application allows users to upload pre-created
 195       raw images.
 196     </p>
 197         <p>
 198       <strong>Recommendation:</strong> never attempt to automatically
 199       detect the format of a disk image based on file contents which
 200       are accessible to / originate from an untrusted source.
 201     </p>
 202         <h3>
 203           <a name="diskimagebacking" shape="rect" id="diskimagebacking">Disk image backing files</a>
 204           <a class="headerlink" href="#diskimagebacking" title="Permalink to this headline">¶</a>
 205         </h3>
 206         <p>
 207       If a management application allows users to upload pre-created
 208       disk images in non-raw formats, it can be tricked into giving
 209       the user access to arbitrary host files via the copy-on-write
 210       backing file feature. This is because the qcow2 disk format
 211       header contains a filename field which can point to any location.
 212       It can also point to network protocols such as NBD, HTTP, GlusterFS,
 213       RBD and more. This could allow for compromise of almost arbitrary
 214       data accessible on the LAN/WAN.
 215     </p>
 216         <p>
 217       <strong>Recommendation:</strong> always validate that a disk
 218       image originating from an untrusted source has no backing
 219       file set. If a backing file is seen, reject the image.
 220     </p>
 221         <h3>
 222           <a name="diskimagesize" shape="rect" id="diskimagesize">Disk image size validation</a>
 223           <a class="headerlink" href="#diskimagesize" title="Permalink to this headline">¶</a>
 224         </h3>
 225         <p>
 226       If an application allows users to upload pre-created disk
 227       images in non-raw formats, it is essential to validate the
 228       logical disk image size, rather than the physical disk
 229       image size. Non-raw disk images have a grow-on-demand
 230       capability, so a user can provide a qcow2 image that may
 231       be only 1 MB in size, but is configured to grow to many
 232       TB in size.
 233     </p>
 234         <p>
 235       <strong>Recommendation:</strong> if receiving a non-raw disk
 236       image from an untrusted source, validate the logical image
 237       size stored in the disk image metadata against some finite
 238       limit.
 239     </p>
 240         <h3>
 241           <a name="diskimageaccess" shape="rect" id="diskimageaccess">Disk image data access</a>
 242           <a class="headerlink" href="#diskimageaccess" title="Permalink to this headline">¶</a>
 243         </h3>
 244         <p>
 245       If an untrusted disk image is ever mounted on the host OS by
 246       a management application or administrator, this opens an
 247       avenue of attack with which to potentially compromise the
 248       host kernel. Filesystem drivers in OS kernels are often very
 249       complex code and thus may have bugs lurking in them. With
 250       Linux, there are a large number of filesystem drivers, many
 251       of which attract little security analysis attention. Linux
 252       will helpfully probe filesystem formats if not told to use an
 253       explicit format, allowing an attacker the ability to target
 254       specific weak filesystem drivers. Even commonly used and
 255       widely audited filesystems such as <code>ext4</code> have had
 256       <a href="https://lwn.net/Articles/538898/" shape="rect">bugs lurking in them</a>
 257       undetected for years at a time.
 258     </p>
 259         <p>
 260       <strong>Recommendation:</strong> if there is a need to access
 261       the content of a disk image, use a single-use throwaway virtual
 262       machine to access the data. Never mount disk images on the host
 263       OS. Ideally make use of the <a href="http://libguestfs.org" shape="rect">libguestfs</a>
 264       tools and APIs for accessing disks
 265     </p>
 266         <h2>
 267           <a name="migration" shape="rect" id="migration">Guest migration network</a>
 268           <a class="headerlink" href="#migration" title="Permalink to this headline">¶</a>
 269         </h2>
 270         <p>
 271       Most hypervisors with support for guest migration between hosts
 272       make use of one (or more) network connections. Typically the source
 273       host will connect to some port on the target host to initiate the
 274       migration. There may be separate connections for co-ordinating the
 275       migration, transferring memory state and transferring storage.
 276       If the network over which migration takes place is accessible the
 277       guest, or client applications, there is potential for data leakage
 278       via packet snooping/capture. It is also possible for a malicious
 279       guest or client to make attempts to connect to the target host
 280       to trigger bogus migration operations, or at least inflict a denial
 281       of service attack.
 282     </p>
 283         <p>
 284       <strong>Recommendations:</strong> there are several things to consider
 285       when performing migration
 286     </p>
 287         <ul><li>Use a specific address for establishing the migration
 288         connection which is accessible only to the virtualization
 289         hosts themselves, not libvirt clients or virtual guests.
 290         Most hypervisors allow the management application to provide
 291         the IP address of the target host as a way to
 292         determine which network migration takes place on. This is
 293         effectively the connect() socket address for the source host.</li><li>Use a specific address for listening for incoming migration
 294         connections which is accessible only to the virtualization
 295         hosts themselves, not libvirt clients or virtual guests.
 296         Most hypervisors allow the management application to configure
 297         the IP address on which the target host listens. This is
 298         the bind() socket address for the target host.</li><li>Use an encrypted migration protocol. Some hypervisors
 299         have support for encrypting the migration memory/storage
 300         data. In other cases it can be tunnelled over the libvirtd
 301         RPC protocol connections.</li></ul>
 302         <h2>
 303           <a name="storage" shape="rect" id="storage">Storage encryption</a>
 304           <a class="headerlink" href="#storage" title="Permalink to this headline">¶</a>
 305         </h2>
 306         <p>
 307       Virtual disk images will typically contain confidential data
 308       belonging to the owner of the virtual machine. It is desirable
 309       to protect this against data center administrators as much as
 310       possible. For example, a rogue storage administrator may attempt
 311       to access disk contents directly from a storage host, or a network
 312       administrator/attack may attempt to snoop on data packets relating
 313       to storage access. Use of disk encryption on the virtualization
 314       host can ensure that only the virtualization host administrator
 315       can see the plain text contents of disk images.
 316     </p>
 317         <p>
 318       <strong>Recommendation:</strong> make use of storage encryption
 319       to protect non-local storage from attack by rogue network /
 320       storage administrators or external attackers. This is particularly
 321       important if the storage protocol itself does not offer any kind
 322       of encryption capabilities.
 323     </p>
 324       </div>
 325     </div>
 326     <div id="footer">
 327       <p id="sponsor">
 328             Sponsored by:<br /><a href="http://et.redhat.com/"><img src="et.png" alt="Project sponsored by Red Hat Emerging Technology" /></a></p>
 329     </div>
 330   </body>
 331 </html>