From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36467) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c7jL6-0007kX-3m for qemu-devel@nongnu.org; Fri, 18 Nov 2016 08:36:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c7jL2-0002mR-UD for qemu-devel@nongnu.org; Fri, 18 Nov 2016 08:36:24 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41658) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c7jL2-0002lY-Kh for qemu-devel@nongnu.org; Fri, 18 Nov 2016 08:36:20 -0500 Date: Fri, 18 Nov 2016 13:36:11 +0000 From: "Daniel P. Berrange" Message-ID: <20161118133611.GC5371@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> <4F9BDA10-1D17-4420-A332-9834E84BF0BC@veritas.com> <20161118115450.GB5371@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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 01:25:43PM +0000, Ketan Nilangekar wrote: > > > > On Nov 18, 2016, at 5:25 PM, Daniel P. Berrange wrote: > > > >> On Fri, Nov 18, 2016 at 11:36:02AM +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. > >> > >> Just so I am clear on this, how will such an escaped guest get to know > >> the other guest vdisk IDs? > > > > There can be a multiple approaches depending on the deployment scenario. > > At the very simplest it could directly read the IDs out of the libvirt > > XML files in /var/run/libvirt. Or it can rnu "ps" to list other running > > QEMU processes and see the vdisk IDs in the command line args of those > > processes. Or the mgmt app may be creating vdisk IDs based on some > > particular scheme, and the attacker may have info about this which lets > > them determine likely IDs. Or the QEMU may have previously been > > permitted to the use the disk and remembered the ID for use later > > after access to the disk has been removed. > > > > Are we talking about a compromised guest here or compromised hypervisor? > How will a compromised guest read the xml file or list running qemu > processes? Compromised QEMU process, aka hypervisor userspace 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/ :|