12:06 p.m.
From: "Daniel P. Berrange" <berrange(a)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(a)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
2:58 p.m.
On 10/14/2013 11:06 AM, Daniel P. Berrange wrote:
From: "Daniel P. Berrange" <berrange(a)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(a)redhat.com>
---
docs/secureusage.html.in | 169 +++++++++++++++++++++++++++++++++++++++++++++++
docs/sitemap.html.in | 4 ++
2 files changed, 173 insertions(+)
create mode 100644 docs/secureusage.html.in
+
+ <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>
Maybe worth a mention that granting someone access to the system
libvirtd with the permission for writing domain XML is effectively
granting them full access to the entire machine (since they can create a
domain that points to an arbitrary file and use the guest to alter that
file's contents). Also: while sVirt protects one guest from another, it
does not protect guests from a bad admin on the host. But this could be
added in a followup patch, if you wanted to get the framework in and
still get a content review of new text.
+ <p>
+ Historically there have been multiple flaws in QEMU and most
+ projects using QEMUs, related to handling of disk formats.
Not sure what you meant by 'QEMUs' - maybe just 'QEMU'?
+ if the management application allows users to upload
pre-created
+ raw images
s/$/./
+ <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
s/attacker/attack/
+ 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
s/helpfull/helpfully/
+ <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
s/mgmt/management/
+ 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>
Are 1 and 3 identical?
More docs are always an improvement, so ACK with those issues fixed.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
5:02 a.m.
On Mon, Oct 14, 2013 at 01:58:29PM -0600, Eric Blake wrote:
On 10/14/2013 11:06 AM, Daniel P. Berrange wrote:
> From: "Daniel P. Berrange" <berrange(a)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(a)redhat.com>
> ---
> docs/secureusage.html.in | 169 +++++++++++++++++++++++++++++++++++++++++++++++
> docs/sitemap.html.in | 4 ++
> 2 files changed, 173 insertions(+)
> create mode 100644 docs/secureusage.html.in
>
> +
> + <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>
Maybe worth a mention that granting someone access to the system
libvirtd with the permission for writing domain XML is effectively
granting them full access to the entire machine (since they can create a
domain that points to an arbitrary file and use the guest to alter that
file's contents). Also: while sVirt protects one guest from another, it
does not protect guests from a bad admin on the host. But this could be
added in a followup patch, if you wanted to get the framework in and
still get a content review of new text.
Ahhh, yes, I knew there was one thing section I wanted to a write.
I'll send a followup with more data.
> + <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
s/mgmt/management/
> + 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>
Are 1 and 3 identical?
One is about the connect() address for source QEMU and the other
is about bind() address for dest QEMU.
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
4056
days inactive
4057
days old
2 comments
2 participants
participants (2)
-
Daniel P. Berrange -
Eric Blake