On 10/14/2013 11:06 AM, Daniel P. Berrange wrote: > From: "Daniel P. Berrange" <berrange@xxxxxxxxxx> > > 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@xxxxxxxxxx> > --- > 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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list