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