Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support

["Daniel P. Berrange" <berrange@redhat.com>]

On Fri, Nov 18, 2016 at 10:57:00AM +0000, Ketan Nilangekar wrote:
> 
> 
> 
> 
> 
> On 11/18/16, 3:32 PM, "Stefan Hajnoczi" <stefanha@gmail.com> wrote:
> 
> >On Fri, Nov 18, 2016 at 02:26:21AM -0500, Jeff Cody wrote:
> >> * Daniel pointed out that there is no authentication method for taking to a
> >>   remote server.  This seems a bit scary.  Maybe all that is needed here is
> >>   some clarification of the security scheme for authentication?  My
> >>   impression from above is that you are relying on the networks being
> >>   private to provide some sort of implicit authentication, though, and this
> >>   seems fragile (and doesn't protect against a compromised guest or other
> >>   process on the server, for one).
> >
> >Exactly, from the QEMU trust model you must assume that QEMU has been
> >compromised by the guest.  The escaped guest can connect to the VxHS
> >server since it controls the QEMU process.
> >
> >An escaped guest must not have access to other guests' volumes.
> >Therefore authentication is necessary.
> >
> >By the way, QEMU has a secrets API for providing passwords and other
> >sensistive data without passing them on the command-line.  The
> >command-line is vulnerable to snooping by other processes so using this
> >API is mandatory.  Please see include/crypto/secret.h.
> 
> Stefan, do you have any details on the authentication implemented by
> qemu-nbd as part of the nbd protocol?

Historically the NBD protocol has zero authentication or encryption
facilities.

I recently added support for running TLS over the NBD channel. When
doing this, the server is able to request an x509 certificate from
the client and use the distinguished name from the cert as an identity
against which to control access.

The glusterfs protocol takes a similar approach of using TLS and x509
certs to provide identies for access control.

The Ceph/RBD protocol uses an explicit username+password pair.

NFS these days can use Kerberos

My recommendation would be either TLS with x509 certs, or to integrate
with SASL which is a pluggable authentication framework, or better yet
to support both.  This is what we do for VNC & SPICE auth, as well as
for libvirt auth

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|