From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54836) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c7gxI-0000qp-NR for qemu-devel@nongnu.org; Fri, 18 Nov 2016 06:03:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c7gxE-0008G3-SR for qemu-devel@nongnu.org; Fri, 18 Nov 2016 06:03:40 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37832) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c7gxE-0008F6-IR for qemu-devel@nongnu.org; Fri, 18 Nov 2016 06:03:36 -0500 Date: Fri, 18 Nov 2016 11:03:27 +0000 From: "Daniel P. Berrange" Message-ID: <20161118110327.GA5371@redhat.com> Reply-To: "Daniel P. Berrange" References: <1475035789-685-1-git-send-email-ashish.mittal@veritas.com> <20160928214510.GA2837@stefanha-x1.localdomain> <20161118072621.GA2607@localhost.localdomain> <20161118100210.GA28853@stefanha-x1.localdomain> <93FCEEA7-344E-45D8-9BA9-5DD88E1D726C@veritas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <93FCEEA7-344E-45D8-9BA9-5DD88E1D726C@veritas.com> Subject: Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ketan Nilangekar Cc: Stefan Hajnoczi , Jeff Cody , ashish mittal , qemu-devel , Paolo Bonzini , Kevin Wolf , Markus Armbruster , Fam Zheng , Ashish Mittal , Abhijit Dey , Buddhi Madhav , "Venkatesha M.G." On Fri, Nov 18, 2016 at 10:57:00AM +0000, Ketan Nilangekar wrote: > > > > > > On 11/18/16, 3:32 PM, "Stefan Hajnoczi" 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/ :|