/usr/share/doc/libvirt-doc/secureusage.html is in libvirt-doc 1.3.1-1ubuntu10.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 | <?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">
<!--
This file is autogenerated from secureusage.html.in
Do not edit this file. Changes will be lost.
-->
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<link rel="stylesheet" type="text/css" href="main.css" />
<link rel="SHORTCUT ICON" href="32favicon.png" />
<title>libvirt: Secure Usage of Libvirt</title>
<meta name="description" content="libvirt, virtualization, virtualization API" />
</head>
<body>
<div id="header">
<div id="headerLogo"></div>
<div id="headerSearch">
<form action="search.php" enctype="application/x-www-form-urlencoded" method="get"><div>
<input id="query" name="query" type="text" size="12" value="" />
<input id="submit" name="submit" type="submit" value="Search" />
</div></form>
</div>
</div>
<div id="body">
<div id="menu">
<ul class="l0"><li>
<div>
<a title="Front page of the libvirt website" class="inactive" href="index.html">Home</a>
</div>
</li><li>
<div>
<a title="Details of new features and bugs fixed in each release" class="inactive" href="news.html">News</a>
</div>
</li><li>
<div>
<a title="Applications known to use libvirt" class="inactive" href="apps.html">Applications</a>
</div>
</li><li>
<div>
<a title="Get the latest source releases, binary builds and get access to the source repository" class="inactive" href="downloads.html">Downloads</a>
</div>
</li><li>
<div>
<a title="Information for users, administrators and developers" class="active" href="docs.html">Documentation</a>
<ul class="l1"><li>
<div>
<a title="How to compile libvirt" class="inactive" href="compiling.html">Compiling</a>
</div>
</li><li>
<div>
<a title="Information about deploying and using libvirt" class="inactive" href="deployment.html">Deployment</a>
</div>
</li><li>
<div>
<a title="Overview of the logical subsystems in the libvirt API" class="active" href="intro.html">Architecture</a>
<ul class="l2"><li>
<div>
<a title="Terminology and goals of libvirt API" class="inactive" href="goals.html">Goals</a>
</div>
</li><li>
<div>
<a title="The libvirt API concepts" class="inactive" href="api.html">API concepts</a>
</div>
</li><li>
<div>
<a title="Managing virtual machines" class="inactive" href="archdomain.html">Domains</a>
</div>
</li><li>
<div>
<a title="Providing isolated networks and NAT based network connectivity" class="inactive" href="archnetwork.html">Network</a>
</div>
</li><li>
<div>
<a title="Managing storage pools and volumes" class="inactive" href="archstorage.html">Storage</a>
</div>
</li><li>
<div>
<a title="Enumerating host node devices" class="inactive" href="archnode.html">Node Devices</a>
</div>
</li><li>
<div>
<span class="active">Secure usage</span>
</div>
</li></ul>
</div>
</li><li>
<div>
<a title="Description of the XML formats used in libvirt" class="inactive" href="format.html">XML format</a>
</div>
</li><li>
<div>
<a title="Hypervisor specific driver information" class="inactive" href="drivers.html">Drivers</a>
</div>
</li><li>
<div>
<a title="Reference manual for the C public API" class="inactive" href="html/index.html">API reference</a>
</div>
</li><li>
<div>
<a title="Bindings of the libvirt API for other languages" class="inactive" href="bindings.html">Language bindings</a>
</div>
</li><li>
<div>
<a title="Working on the internals of libvirt API, driver and daemon code" class="inactive" href="internals.html">Internals</a>
</div>
</li><li>
<div>
<a title="A guide and reference for developing with libvirt" class="inactive" href="devguide.html">Development Guide</a>
</div>
</li><li>
<div>
<a title="Command reference for virsh" class="inactive" href="virshcmdref.html">Virsh Commands</a>
</div>
</li><li>
<div>
<a title="Project governance and code of conduct" class="inactive" href="governance.html">Governance</a>
</div>
</li></ul>
</div>
</li><li>
<div>
<a title="User contributed content" class="inactive" href="http://wiki.libvirt.org">Wiki</a>
</div>
</li><li>
<div>
<a title="Frequently asked questions" class="inactive" href="http://wiki.libvirt.org/page/FAQ">FAQ</a>
</div>
</li><li>
<div>
<a title="How and where to report bugs and request features" class="inactive" href="bugs.html">Bug reports</a>
</div>
</li><li>
<div>
<a title="How to contact the developers via email and IRC" class="inactive" href="contact.html">Contact</a>
</div>
</li><li>
<div>
<a title="Available test suites for libvirt" class="inactive" href="testsuites.html">Test suites</a>
</div>
</li><li>
<div>
<a title="Miscellaneous links of interest related to libvirt" class="inactive" href="relatedlinks.html">Related Links</a>
</div>
</li><li>
<div>
<a title="Overview of all content on the website" class="inactive" href="sitemap.html">Sitemap</a>
</div>
</li></ul>
</div>
<div id="content">
<h1>Secure Usage of Libvirt</h1>
<ul><li>
<a href="#diskimage">Disk image handling</a>
<ul><li>
<a href="#diskimageformat">Disk image format probing</a>
</li><li>
<a href="#diskimagebacking">Disk image backing files</a>
</li><li>
<a href="#diskimagesize">Disk image size validation</a>
</li><li>
<a href="#diskimageaccess">Disk image data access</a>
</li></ul>
</li><li>
<a href="#migration">Guest migration network</a>
</li><li>
<a href="#storage">Storage encryption</a>
</li></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" shape="rect" id="diskimage">Disk image handling</a>
<a class="headerlink" href="#diskimage" title="Permalink to this headline">¶</a>
</h2>
<h3>
<a name="diskimageformat" shape="rect" id="diskimageformat">Disk image format probing</a>
<a class="headerlink" href="#diskimageformat" title="Permalink to this headline">¶</a>
</h3>
<p>
Historically there have been multiple flaws in QEMU and most
projects using QEMU, 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" shape="rect" id="diskimagebacking">Disk image backing files</a>
<a class="headerlink" href="#diskimagebacking" title="Permalink to this headline">¶</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" shape="rect" id="diskimagesize">Disk image size validation</a>
<a class="headerlink" href="#diskimagesize" title="Permalink to this headline">¶</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" shape="rect" id="diskimageaccess">Disk image data access</a>
<a class="headerlink" href="#diskimageaccess" title="Permalink to this headline">¶</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 attack 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 helpfully 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/" shape="rect">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" shape="rect">libguestfs</a>
tools and APIs for accessing disks
</p>
<h2>
<a name="migration" shape="rect" id="migration">Guest migration network</a>
<a class="headerlink" href="#migration" title="Permalink to this headline">¶</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 management application to provide
the IP address of the target host as a way to
determine which network migration takes place on. This is
effectively the connect() socket address for the source host.</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 management application to configure
the IP address on which the target host listens. This is
the bind() socket address for the target host.</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></ul>
<h2>
<a name="storage" shape="rect" id="storage">Storage encryption</a>
<a class="headerlink" href="#storage" title="Permalink to this headline">¶</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>
</div>
</div>
<div id="footer">
<p id="sponsor">
Sponsored by:<br /><a href="http://et.redhat.com/"><img src="et.png" alt="Project sponsored by Red Hat Emerging Technology" /></a></p>
</div>
</body>
</html>
|