[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH for-5.1 2/3] virtiofsd: add container-friendly -o chroot sand
From: |
Daniel P . Berrangé |
Subject: |
Re: [PATCH for-5.1 2/3] virtiofsd: add container-friendly -o chroot sandboxing option |
Date: |
Wed, 22 Jul 2020 17:58:11 +0100 |
User-agent: |
Mutt/1.14.5 (2020-06-23) |
On Wed, Jul 22, 2020 at 02:02:05PM +0100, Stefan Hajnoczi wrote:
> virtiofsd cannot run in an unprivileged container because CAP_SYS_ADMIN
> is required to create namespaces.
>
> Introduce a weaker sandbox that is sufficient in container environments
> because the container runtime already sets up namespaces. Use chroot to
> restrict path traversal to the shared directory.
>
> virtiofsd loses the following:
>
> 1. Mount namespace. The process chroots to the shared directory but
> leaves the mounts in place. Seccomp rejects mount(2)/umount(2)
> syscalls.
>
> 2. Pid namespace. This should be fine because virtiofsd is the only
> process running in the container.
>
> 3. Network namespace. This should be fine because seccomp already
> rejects the connect(2) syscall, but an additional layer of security
> is lost. Container runtime-specific network security policies can be
> used drop network traffic (except for the vhost-user UNIX domain
> socket).
IIUC this relies on the fact that the container will still have
CAP_SYS_CHROOT IOW, we still don't have a solution for running
virtiofsd as an unprivileged user.
Bearing in mind possibly need for future improvements to handle
unprivileged users....
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> ---
> tools/virtiofsd/helper.c | 3 +++
> tools/virtiofsd/passthrough_ll.c | 44 ++++++++++++++++++++++++++++++--
> 2 files changed, 45 insertions(+), 2 deletions(-)
>
> diff --git a/tools/virtiofsd/helper.c b/tools/virtiofsd/helper.c
> index 3105b6c23a..7421c9ca1a 100644
> --- a/tools/virtiofsd/helper.c
> +++ b/tools/virtiofsd/helper.c
> @@ -151,6 +151,9 @@ void fuse_cmdline_help(void)
> " -o cache=<mode> cache mode. could be one of
> \"auto, "
> "always, none\"\n"
> " default: auto\n"
> + " -o chroot|no_chroot use container-friendly chroot
> instead\n"
> + " of stronger mount namespace
> sandbox\n"
> + " default: false\n"
A simple boolean like this feels like it lacks future-proofing.
Should we have an option that takes an enumerated arg string:
-o sandbox=[namespace|chroot|....]
so we can add more options later with the same syntax.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|