qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: vromanso@redhat.com, Daniel Walsh <dwalsh@redhat.com>,
	qemu-devel@nongnu.org, rmohr@redhat.com, virtio-fs@redhat.com,
	mpatel@redhat.com, vgoyal@redhat.com
Subject: Re: [PATCH v2 0/3] virtiofsd: allow virtiofsd to run in a container
Date: Thu, 27 Aug 2020 19:40:13 +0100	[thread overview]
Message-ID: <20200827184013.GG2837@work-vm> (raw)
In-Reply-To: <20200727190223.422280-1-stefanha@redhat.com>

* Stefan Hajnoczi (stefanha@redhat.com) wrote:
> v2:
>  * Update virtiofsd.rst documentation on sandboxing modes
>  * Change syntax to -o sandbox=namespace|chroot
>  * Add comment explaining that unshare(CLONE_FS) has no visible side-effect
>    while single-threaded
>  * xfstests and pjdfstest pass. Did not run tests on overlayfs because required
>    xattrs do not work without CAP_SYS_ADMIN.
> 
> Mrunal and Dan: This patch series adds a sandboxing mode where virtiofsd relies
> on the container runtime for isolation. It only does
> chroot("path/to/shared-dir"), seccomp, and drops Linux capabilities. Previously
> it created a new mount, pid, and net namespace but cannot do this without
> CAP_SYS_ADMIN when run inside a container. pivot_root("path/to/shared-dir") has
> been replaced with chroot("path/to/shared-dir"), again because CAP_SYS_ADMIN is
> unavailable. The point of the chroot() is to prevent escapes from the shared
> directory during path traversal. Does this ring any alarm bells or does it
> sound sane?
> 
> Container runtimes handle namespace setup and remove privileges needed by
> virtiofsd to perform sandboxing. Luckily the container environment already
> provides most of the sandbox that virtiofsd needs for security.
> 
> Introduce a new "virtiofsd -o sandbox=chroot" option that uses chroot(2)
> instead of namespaces. This option allows virtiofsd to work inside a container.
> 
> Please see the individual patches for details on the changes and security
> implications.
> 
> Given that people are starting to attempt running virtiofsd in containers I
> think this should go into QEMU 5.1.

I've queued 1 and 3; waiting for someone with better knowledge of chroot
to review 2.

Dave

> Stefan Hajnoczi (3):
>   virtiofsd: drop CAP_DAC_READ_SEARCH
>   virtiofsd: add container-friendly -o sandbox=chroot option
>   virtiofsd: probe unshare(CLONE_FS) and print an error
> 
>  tools/virtiofsd/fuse_virtio.c    | 16 +++++++++
>  tools/virtiofsd/helper.c         |  8 +++++
>  tools/virtiofsd/passthrough_ll.c | 58 ++++++++++++++++++++++++++++++--
>  docs/tools/virtiofsd.rst         | 32 ++++++++++++++----
>  4 files changed, 104 insertions(+), 10 deletions(-)
> 
> -- 
> 2.26.2
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK



      parent reply	other threads:[~2020-08-27 18:41 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-27 19:02 [PATCH v2 0/3] virtiofsd: allow virtiofsd to run in a container Stefan Hajnoczi
2020-07-27 19:02 ` [PATCH v2 1/3] virtiofsd: drop CAP_DAC_READ_SEARCH Stefan Hajnoczi
2020-07-27 19:02 ` [PATCH v2 2/3] virtiofsd: add container-friendly -o sandbox=chroot option Stefan Hajnoczi
2020-08-07 15:36   ` Dr. David Alan Gilbert
2020-07-27 19:02 ` [PATCH v2 3/3] virtiofsd: probe unshare(CLONE_FS) and print an error Stefan Hajnoczi
2020-07-28  1:05   ` misono.tomohiro
2020-07-28 10:00     ` Roman Mohr
2020-07-28 13:12       ` Vivek Goyal
2020-07-28 15:52         ` Daniel P. Berrangé
2020-07-28 20:54           ` Vivek Goyal
2020-07-28 19:12         ` Daniel Walsh
2020-07-28 21:01           ` Vivek Goyal
2020-07-29  7:59         ` Roman Mohr
2020-07-29 14:40           ` Stefan Hajnoczi
2020-07-30 22:21             ` Daniel Walsh
2020-07-31  8:26               ` Stefan Hajnoczi
2020-07-31  8:39                 ` Roman Mohr
2020-07-31 14:11                   ` Stefan Hajnoczi
2020-07-28 15:32       ` Stefan Hajnoczi
2020-07-28 19:15         ` Daniel Walsh
2020-07-29 14:29           ` Stefan Hajnoczi
2020-08-07 15:29     ` Dr. David Alan Gilbert
2020-08-27 18:40 ` Dr. David Alan Gilbert [this message]

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=20200827184013.GG2837@work-vm \
    --to=dgilbert@redhat.com \
    --cc=dwalsh@redhat.com \
    --cc=mpatel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rmohr@redhat.com \
    --cc=stefanha@redhat.com \
    --cc=vgoyal@redhat.com \
    --cc=virtio-fs@redhat.com \
    --cc=vromanso@redhat.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).