From: "Daniel P. Berrange" <berrange@redhat.com>
To: Ketan Nilangekar <Ketan.Nilangekar@veritas.com>
Cc: Stefan Hajnoczi <stefanha@gmail.com>,
Jeff Cody <jcody@redhat.com>, ashish mittal <ashmit602@gmail.com>,
qemu-devel <qemu-devel@nongnu.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Kevin Wolf <kwolf@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
Fam Zheng <famz@redhat.com>,
Ashish Mittal <Ashish.Mittal@veritas.com>,
Abhijit Dey <Abhijit.Dey@veritas.com>,
Buddhi Madhav <Buddhi.Madhav@veritas.com>,
"Venkatesha M.G." <Venkatesha.Mg@veritas.com>
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 [thread overview]
Message-ID: <20161118115450.GB5371@redhat.com> (raw)
In-Reply-To: <4F9BDA10-1D17-4420-A332-9834E84BF0BC@veritas.com>
On Fri, Nov 18, 2016 at 11:36:02AM +0000, Ketan Nilangekar wrote:
>
>
>
>
>
> On 11/18/16, 3:32 PM, "Stefan Hajnoczi" <stefanha@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.
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/ :|
next prev parent reply other threads:[~2016-11-18 11:55 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-28 4:09 [Qemu-devel] [PATCH v7 RFC] block/vxhs: Initial commit to add Veritas HyperScale VxHS block device support Ashish Mittal
2016-09-28 11:12 ` Paolo Bonzini
2016-09-28 11:13 ` Stefan Hajnoczi
2016-10-05 4:02 ` Jeff Cody
2016-10-11 7:56 ` ashish mittal
2016-10-18 19:10 ` Jeff Cody
2016-10-19 20:01 ` Ketan Nilangekar
2016-09-28 11:36 ` Stefan Hajnoczi
2016-09-28 12:06 ` Daniel P. Berrange
2016-09-28 21:45 ` Stefan Hajnoczi
2016-11-14 15:05 ` Stefan Hajnoczi
2016-11-14 18:01 ` ashish mittal
2016-11-15 22:38 ` ashish mittal
2016-11-16 8:12 ` Stefan Hajnoczi
2016-11-18 7:26 ` Jeff Cody
2016-11-18 8:57 ` Daniel P. Berrange
2016-11-18 10:02 ` Stefan Hajnoczi
2016-11-18 10:57 ` Ketan Nilangekar
2016-11-18 11:03 ` Daniel P. Berrange
2016-11-18 11:36 ` Ketan Nilangekar
2016-11-18 11:54 ` Daniel P. Berrange [this message]
2016-11-18 13:25 ` Ketan Nilangekar
2016-11-18 13:36 ` Daniel P. Berrange
2016-11-23 8:25 ` Ketan Nilangekar
2016-11-23 22:09 ` ashish mittal
2016-11-23 22:37 ` Paolo Bonzini
2016-11-24 5:44 ` Ketan Nilangekar
2016-11-24 11:11 ` Stefan Hajnoczi
2016-11-24 11:31 ` Ketan Nilangekar
2016-11-24 16:08 ` Stefan Hajnoczi
2016-11-25 8:27 ` Ketan Nilangekar
2016-11-25 11:35 ` Stefan Hajnoczi
2016-11-28 10:23 ` Ketan Nilangekar
2016-11-28 14:17 ` Stefan Hajnoczi
2016-11-30 0:45 ` ashish mittal
2016-11-30 4:20 ` Rakesh Ranjan
2016-11-30 8:35 ` Stefan Hajnoczi
2016-11-30 9:01 ` Stefan Hajnoczi
2016-11-28 7:15 ` Fam Zheng
2016-11-24 10:15 ` Daniel P. Berrange
2016-11-18 10:34 ` Ketan Nilangekar
2016-11-18 14:49 ` Markus Armbruster
2016-11-18 16:19 ` Jeff Cody
2016-09-29 1:46 ` Jeff Cody
2016-09-29 2:18 ` Jeff Cody
2016-09-29 17:30 ` ashish mittal
2016-09-30 8:36 ` Stefan Hajnoczi
2016-10-01 3:10 ` ashish mittal
2016-10-03 14:10 ` Stefan Hajnoczi
2016-10-20 1:31 ` Ketan Nilangekar
2016-10-24 14:24 ` Paolo Bonzini
2016-10-25 1:56 ` Abhijit Dey
2016-10-25 5:07 ` Ketan Nilangekar
2016-10-25 5:15 ` Abhijit Dey
2016-10-25 11:01 ` Paolo Bonzini
2016-10-25 21:53 ` Ketan Nilangekar
2016-10-25 21:59 ` Paolo Bonzini
[not found] ` <21994ADD-7BC5-4C77-8D18-C1D4F9A52277@veritas.com>
[not found] ` <ac0aa87f-702d-b53f-a6b7-2257b25a4a2a@redhat.com>
2016-10-26 22:17 ` Ketan Nilangekar
2016-11-04 9:49 ` Stefan Hajnoczi
2016-11-04 18:44 ` Ketan Nilangekar
2016-11-04 9:52 ` Stefan Hajnoczi
2016-11-04 18:30 ` Ketan Nilangekar
2016-11-07 10:22 ` Stefan Hajnoczi
2016-11-07 20:27 ` Ketan Nilangekar
2016-11-08 15:39 ` Stefan Hajnoczi
2016-11-09 12:47 ` Paolo Bonzini
-- strict thread matches above, loose matches on Subject: below --
2016-12-14 0:06 ashish mittal
2016-12-14 7:23 ` Stefan Hajnoczi
2016-12-16 1:42 ` Buddhi Madhav
2016-12-16 8:09 ` Stefan Hajnoczi
2017-02-01 23:59 ` Ketan Nilangekar
2017-02-02 9:53 ` Daniel P. Berrange
2017-02-02 10:07 ` Stefan Hajnoczi
2017-02-02 10:15 ` Daniel P. Berrange
2017-02-02 20:57 ` Ketan Nilangekar
2017-02-02 21:22 ` Ketan Nilangekar
2017-02-03 9:45 ` Daniel P. Berrange
2017-02-03 21:32 ` Ketan Nilangekar
2017-02-02 20:53 ` Ketan Nilangekar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161118115450.GB5371@redhat.com \
--to=berrange@redhat.com \
--cc=Abhijit.Dey@veritas.com \
--cc=Ashish.Mittal@veritas.com \
--cc=Buddhi.Madhav@veritas.com \
--cc=Ketan.Nilangekar@veritas.com \
--cc=Venkatesha.Mg@veritas.com \
--cc=armbru@redhat.com \
--cc=ashmit602@gmail.com \
--cc=famz@redhat.com \
--cc=jcody@redhat.com \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).