On 10/14/2013 11:06 AM, Daniel P. Berrange wrote:
From: "Daniel P. Berrange" <berrange@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@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