From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60635) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c7jAs-0004VU-DM for qemu-devel@nongnu.org; Fri, 18 Nov 2016 08:25:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c7jAo-0006wx-Td for qemu-devel@nongnu.org; Fri, 18 Nov 2016 08:25:50 -0500 Received: from mail1.bemta12.messagelabs.com ([216.82.251.7]:9736) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c7jAo-0006vc-Ms for qemu-devel@nongnu.org; Fri, 18 Nov 2016 08:25:46 -0500 From: Ketan Nilangekar Date: Fri, 18 Nov 2016 13:25:43 +0000 Message-ID: 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> In-Reply-To: <20161118115450.GB5371@redhat.com> Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: "Daniel P. Berrange" 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 Nov 18, 2016, at 5:25 PM, Daniel P. Berrange wro= te: >=20 >> On Fri, Nov 18, 2016 at 11:36:02AM +0000, Ketan Nilangekar wrote: >>=20 >>=20 >>=20 >>=20 >>=20 >>> On 11/18/16, 3:32 PM, "Stefan Hajnoczi" wrote: >>>=20 >>>> 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 her= e 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 oth= er >>>> process on the server, for one). >>>=20 >>> 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. >>>=20 >>> An escaped guest must not have access to other guests' volumes. >>> Therefore authentication is necessary. >>=20 >> Just so I am clear on this, how will such an escaped guest get to know >> the other guest vdisk IDs? >=20 > 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. >=20 Are we talking about a compromised guest here or compromised hypervisor? Ho= w will a compromised guest read the xml file or list running qemu processes= ? > IOW, you can't rely on security-through-obscurity of the vdisk IDs >=20 > Regards, > Daniel > --=20 > |: http://berrange.com -o- http://www.flickr.com/photos/dberrange= / :| > |: http://libvirt.org -o- http://virt-manager.or= g :| > |: http://entangle-photo.org -o- http://search.cpan.org/~danberr= / :|