qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Verita


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support
Date: Fri, 18 Nov 2016 11:54:50 +0000
User-agent: Mutt/1.7.1 (2016-10-04)

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.

IOW, you can't rely on security-through-obscurity of the vdisk IDs

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/ :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]