+Nitin Jerath from Veritas.
On 11/18/16, 7:06 PM, "Daniel P. Berrange" <berra...@redhat.com> 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 <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/ :|