[libvirt] [PATCH] Add some notes about secure usage of libvirt

[Daniel P. Berrange]

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 at 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 at 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 :|