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
prev 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).