All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: virtio-fs@redhat.com, vromanso@redhat.com, qemu-devel@nongnu.org,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	rmohr@redhat.com
Subject: Re: [PATCH for-5.1 2/3] virtiofsd: add container-friendly -o chroot sandboxing option
Date: Thu, 23 Jul 2020 13:17:08 +0100	[thread overview]
Message-ID: <20200723121708.GH186372@stefanha-x1.localdomain> (raw)
In-Reply-To: <20200722165811.GT2324845@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]

On Wed, Jul 22, 2020 at 05:58:11PM +0100, Daniel P. Berrangé wrote:
> 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.

Yes, this still requires root in the container.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Stefan Hajnoczi <stefanha@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: virtio-fs@redhat.com, vromanso@redhat.com, qemu-devel@nongnu.org,
	rmohr@redhat.com
Subject: Re: [Virtio-fs] [PATCH for-5.1 2/3] virtiofsd: add container-friendly -o chroot sandboxing option
Date: Thu, 23 Jul 2020 13:17:08 +0100	[thread overview]
Message-ID: <20200723121708.GH186372@stefanha-x1.localdomain> (raw)
In-Reply-To: <20200722165811.GT2324845@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]

On Wed, Jul 22, 2020 at 05:58:11PM +0100, Daniel P. Berrangé wrote:
> 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.

Yes, this still requires root in the container.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2020-07-23 12:18 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-22 13:02 [PATCH for-5.1 0/3] virtiofsd: allow virtiofsd to run in a container Stefan Hajnoczi
2020-07-22 13:02 ` [Virtio-fs] " Stefan Hajnoczi
2020-07-22 13:02 ` [PATCH for-5.1 1/3] virtiofsd: drop CAP_DAC_READ_SEARCH Stefan Hajnoczi
2020-07-22 13:02   ` [Virtio-fs] " Stefan Hajnoczi
2020-07-22 16:51   ` Dr. David Alan Gilbert
2020-07-22 16:51     ` [Virtio-fs] " Dr. David Alan Gilbert
2020-07-22 13:02 ` [PATCH for-5.1 2/3] virtiofsd: add container-friendly -o chroot sandboxing option Stefan Hajnoczi
2020-07-22 13:02   ` [Virtio-fs] " Stefan Hajnoczi
2020-07-22 16:58   ` Daniel P. Berrangé
2020-07-22 16:58     ` [Virtio-fs] " Daniel P. Berrangé
2020-07-23 12:17     ` Stefan Hajnoczi [this message]
2020-07-23 12:17       ` Stefan Hajnoczi
2020-07-22 17:58   ` Dr. David Alan Gilbert
2020-07-22 17:58     ` [Virtio-fs] " Dr. David Alan Gilbert
2020-07-23 12:28     ` Stefan Hajnoczi
2020-07-23 12:28       ` [Virtio-fs] " Stefan Hajnoczi
2020-07-23 13:47       ` Vivek Goyal
2020-07-23 13:47         ` Vivek Goyal
2020-07-23 15:36         ` Stefan Hajnoczi
2020-07-23 15:36           ` Stefan Hajnoczi
2020-07-22 18:17   ` Vivek Goyal
2020-07-23 12:29     ` Stefan Hajnoczi
2020-07-22 19:03   ` Dr. David Alan Gilbert
2020-07-22 19:03     ` [Virtio-fs] " Dr. David Alan Gilbert
2020-07-23 12:32     ` Stefan Hajnoczi
2020-07-23 12:32       ` [Virtio-fs] " Stefan Hajnoczi
2020-07-23 17:55       ` Dr. David Alan Gilbert
2020-07-23 17:55         ` [Virtio-fs] " Dr. David Alan Gilbert
2020-07-24 12:22         ` Stefan Hajnoczi
2020-07-24 12:22           ` [Virtio-fs] " Stefan Hajnoczi
2020-07-22 13:02 ` [PATCH for-5.1 3/3] virtiofsd: probe unshare(CLONE_FS) and print an error Stefan Hajnoczi
2020-07-22 13:02   ` [Virtio-fs] " Stefan Hajnoczi
2020-07-22 17:03   ` Daniel P. Berrangé
2020-07-22 17:03     ` [Virtio-fs] " Daniel P. Berrangé
2020-07-23 12:46     ` Stefan Hajnoczi
2020-07-23 12:46       ` [Virtio-fs] " Stefan Hajnoczi
2020-07-23 12:50       ` Daniel P. Berrangé
2020-07-23 12:50         ` [Virtio-fs] " Daniel P. Berrangé
2020-07-23 13:56         ` Vivek Goyal
2020-07-23 13:56           ` Vivek Goyal
2020-07-23 15:19           ` Stefan Hajnoczi
2020-07-22 18:19 ` [Virtio-fs] [PATCH for-5.1 0/3] virtiofsd: allow virtiofsd to run in a container Vivek Goyal
2020-07-23 12:46   ` Stefan Hajnoczi

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=20200723121708.GH186372@stefanha-x1.localdomain \
    --to=stefanha@redhat.com \
    --cc=berrange@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rmohr@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.