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

[Ketan Nilangekar]

+Nitin Jerath from Veritas.




On 11/18/16, 7:06 PM, "Daniel P. Berrange" <address@hidden> wrote:

>On Fri, Nov 18, 2016 at 01:25:43PM +0000, Ketan Nilangekar wrote:
>> 
>> 
>> > On Nov 18, 2016, at 5:25 PM, Daniel P. Berrange <address@hidden> wrote:
>> > 
>> >> On Fri, Nov 18, 2016 at 11:36:02AM +0000, Ketan Nilangekar wrote:
>> >> 
>> >> 
>> >> 
>> >> 
>> >> 
>> >>> On 11/18/16, 3:32 PM, "Stefan Hajnoczi" <address@hidden> 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/ :|