Re: [libvirt] [PATCH] Add some notes about secure usage of libvirt
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
Attachments:
- signature.asc (application/pgp-signature — 621 bytes)