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 <ketan.nilange...@veritas.com> wrote: > +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/ :|
