From: Anthony Liguori <aliguori@us.ibm.com>
To: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
libvir-list@redhat.com, Corey Bryant <coreyb@linux.vnet.ibm.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC 0/5] block: File descriptor passing using -open-hook-fd
Date: Tue, 01 May 2012 15:25:42 -0500 [thread overview]
Message-ID: <4FA046C6.5080909@us.ibm.com> (raw)
In-Reply-To: <1335886307-27586-1-git-send-email-stefanha@linux.vnet.ibm.com>
Thanks for sending this out Stefan.
On 05/01/2012 10:31 AM, Stefan Hajnoczi wrote:
> Libvirt can take advantage of SELinux to restrict the QEMU process and prevent
> it from opening files that it should not have access to. This improves
> security because it prevents the attacker from escaping the QEMU process if
> they manage to gain control.
>
> NFS has been a pain point for SELinux because it does not support labels (which
> I believe are stored in extended attributes). In other words, it's not
> possible to use SELinux goodness on QEMU when image files are located on NFS.
> Today we have to allow QEMU access to any file on the NFS export rather than
> restricting specifically to the image files that the guest requires.
>
> File descriptor passing is a solution to this problem and might also come in
> handy elsewhere. Libvirt or another external process chooses files which QEMU
> is allowed to access and provides just those file descriptors - QEMU cannot
> open the files itself.
>
> This series adds the -open-hook-fd command-line option. Whenever QEMU needs to
> open an image file it sends a request over the given UNIX domain socket. The
> response includes the file descriptor or an errno on failure. Please see the
> patches for details on the protocol.
>
> The -open-hook-fd approach allows QEMU to support file descriptor passing
> without changing -drive. It also supports snapshot_blkdev and other commands
> that re-open image files.
>
> Anthony Liguori<aliguori@us.ibm.com> wrote most of these patches. I added a
> demo -open-hook-fd server and added some small fixes. Since Anthony is
> traveling right now I'm sending the RFC for discussion.
What I like about this approach is that it's useful outside the block layer and
is conceptionally simple from a QEMU PoV. We simply delegate open() to libvirt
and let libvirt enforce whatever rules it wants.
This is not meant to be an alternative to blockdev, but even with blockdev, I
think we still want to use a mechanism like this even with blockdev.
Regards,
Anthony Liguori
>
> Anthony Liguori (3):
> block: add open() wrapper that can be hooked by libvirt
> block: add new command line parameter that and protocol description
> block: plumb up open-hook-fd option
>
> Stefan Hajnoczi (2):
> osdep: add qemu_recvmsg() wrapper
> Example -open-hook-fd server
>
> block.c | 107 ++++++++++++++++++++++++++++++++++++++
> block.h | 2 +
> block/raw-posix.c | 18 +++----
> block/raw-win32.c | 2 +-
> block/vdi.c | 2 +-
> block/vmdk.c | 6 +--
> block/vpc.c | 2 +-
> block/vvfat.c | 4 +-
> block_int.h | 12 +++++
> osdep.c | 46 +++++++++++++++++
> qemu-common.h | 2 +
> qemu-options.hx | 42 +++++++++++++++
> test-fd-passing.c | 147 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> vl.c | 3 ++
> 14 files changed, 378 insertions(+), 17 deletions(-)
> create mode 100644 test-fd-passing.c
>
next prev parent reply other threads:[~2012-05-01 20:27 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-01 15:31 [Qemu-devel] [RFC 0/5] block: File descriptor passing using -open-hook-fd Stefan Hajnoczi
2012-05-01 15:31 ` [Qemu-devel] [RFC 1/5] block: add open() wrapper that can be hooked by libvirt Stefan Hajnoczi
2012-05-01 15:31 ` [Qemu-devel] [RFC 2/5] block: add new command line parameter that and protocol description Stefan Hajnoczi
2012-05-02 8:58 ` Daniel P. Berrange
2012-05-02 9:03 ` Daniel P. Berrange
2012-05-01 15:31 ` [Qemu-devel] [RFC 3/5] block: plumb up open-hook-fd option Stefan Hajnoczi
2012-05-01 15:31 ` [Qemu-devel] [RFC 4/5] osdep: add qemu_recvmsg() wrapper Stefan Hajnoczi
2012-05-01 15:31 ` [Qemu-devel] [RFC 5/5] Example -open-hook-fd server Stefan Hajnoczi
2012-05-01 16:04 ` [Qemu-devel] [libvirt] " Stefan Hajnoczi
2012-05-01 20:25 ` Anthony Liguori [this message]
2012-05-01 20:56 ` [Qemu-devel] [libvirt] [RFC 0/5] block: File descriptor passing using -open-hook-fd Eric Blake
2012-05-01 21:52 ` Anthony Liguori
2012-05-02 16:40 ` Paolo Bonzini
2012-05-01 21:45 ` [Qemu-devel] " Corey Bryant
2012-05-01 21:53 ` Anthony Liguori
2012-05-01 22:15 ` [Qemu-devel] [libvirt] " Eric Blake
2012-05-01 22:21 ` Anthony Liguori
2012-05-07 16:10 ` Corey Bryant
2012-05-02 8:20 ` [Qemu-devel] " Kevin Wolf
2012-05-02 8:27 ` Stefan Hajnoczi
2012-05-02 9:38 ` Kevin Wolf
2012-05-02 8:53 ` [Qemu-devel] [libvirt] " Daniel P. Berrange
2012-05-02 9:45 ` Kevin Wolf
2012-05-02 9:56 ` Daniel P. Berrange
2012-05-02 19:25 ` Paolo Bonzini
2012-05-03 19:19 ` Anthony Liguori
2012-05-02 9:01 ` [Qemu-devel] " Daniel P. Berrange
2012-05-04 3:28 ` [Qemu-devel] [libvirt] " Zhi Yong Wu
2012-05-17 13:42 ` Stefan Hajnoczi
2012-05-17 13:57 ` Zhi Yong Wu
2012-05-17 14:02 ` Zhi Yong Wu
2012-05-18 10:38 ` Stefan Hajnoczi
2012-05-17 14:14 ` Eric Blake
2012-05-18 10:38 ` Stefan Hajnoczi
2012-07-09 20:00 ` Anthony Liguori
2012-07-09 20:29 ` Eric Blake
2012-07-09 20:46 ` Anthony Liguori
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=4FA046C6.5080909@us.ibm.com \
--to=aliguori@us.ibm.com \
--cc=coreyb@linux.vnet.ibm.com \
--cc=kwolf@redhat.com \
--cc=libvir-list@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@linux.vnet.ibm.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).