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

[ashish mittal]

On the topic of protocol security -

Would it be enough for the first patch to implement only
authentication and not encryption?

On Wed, Nov 23, 2016 at 12:25 AM, Ketan Nilangekar
<address@hidden> wrote:
> +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/ :|