From: Vivek Goyal <vgoyal@redhat.com>
To: Colin Walters <walters@verbum.org>
Cc: Sergio Lopez <slp@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
virtio-fs-list <virtio-fs@redhat.com>,
qemu-devel@nongnu.org, German Maglione <gmaglione@redhat.com>
Subject: Re: [Virtio-fs] virtiofsd: Any reason why there's not an "openat2" sandbox mode?
Date: Wed, 5 Oct 2022 17:29:54 -0400 [thread overview]
Message-ID: <Yz33UikaqR4cagWK@redhat.com> (raw)
In-Reply-To: <aa26d28d-d352-467c-910c-ab5973a6d759@app.fastmail.com>
On Mon, Oct 03, 2022 at 06:51:42PM -0400, Colin Walters wrote:
>
>
> On Thu, Sep 29, 2022, at 1:03 PM, Vivek Goyal wrote:
> >
> > So rust version of virtiofsd, already supports running unprivileged
> > (inside a user namespace).
>
> I know, but as I already said, the use case here is running inside an OpenShift unprivileged pod where *we are already in a container*.
>
> > host$ podman unshare -- virtiofsd --socket-path=/tmp/vfsd.sock
> > --shared-dir /mnt \
> > --announce-submounts --sandbox chroot &
>
> Yes, but in current OCP 4.11 our seccomp policy denies CLONE_NEWUSER:
Hmm..., no user namespaces allowed.
So sandbox=none in theory should work once we fix it for unprivileged
user.
https://gitlab.com/virtio-fs/virtiofsd/-/merge_requests/136
Given you are already running inside a pod/container, not sure if
locking down virtiofsd with openat2(RESOLVE_IN_ROOT)/landlock is
must for you from security point of view. virtiofsd should not be
able to access anything outside the pod/container anyway and can
only affect things inside the pod/container.
Once we add support for openat2(). Next issue is do you need
arbitrary uid/gid support. By default it will be a single uid/gid
filesystem. Is that enough for your use case? Or inside the guest
you need to be able to switch between arbitrary uid/gid on this
virtiofs filesystem.
>
> ```
> $ unshare -m
> unshare: unshare failed: Function not implemented
> ```
>
> https://docs.openshift.com/container-platform/4.11/security/seccomp-profiles.html
>
> > I think only privileged operation it needs is assigning a range of
> > subuid/subgid to the uid you are using on host.
>
> We also turn on NO_NEW_PRIVILEGES by default in OCP pods.
>
> Now, I *could* in general get elevated permissions where I need to today. But it's also really important to me to have a long term goal of having operating system builds and tests work well as "just another workload" in our production container platform (now, one *does* want to bind in /dev/kvm, but that's generally safe, and even that strictly speaking is optional if one can stomach the ~10x perf hit).
I am assuming this 10x performance hit is being compared with native
container build and test where no VM will be launched.
>
> > Can you give rust virtiofsd (unprivileged) a try.
>
> I admit to not actually trying it in a pod, but I think we all agree it can't work, and the only thing that can today is openat2.
Agreed. Right now we rely on using user namespace for unpriviliged use
case.
We should be able to enable sandbox=none for unprivileged user (no user
namespace) and possibly add openat2() support as well.
I think being able to provide arbitrary uid/gid support will be more
tricky and more work. It will need to store actual uid/gid into some
sort of user xattr. (as done by 9pfs and fuse-overlay and libkrun etc).
And I will not be surprised that there are bunch of corner cases using
that approach. (setuid/setgid automatic clearing etc.)
Thanks
Vivek
next prev parent reply other threads:[~2022-10-05 21:29 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4362261a-c762-4666-84e2-03c9daa6c4d9@www.fastmail.com>
2022-09-27 16:37 ` [Virtio-fs] virtiofsd: Any reason why there's not an "openat2" sandbox mode? Vivek Goyal
2022-09-27 16:57 ` Vivek Goyal
2022-09-27 17:27 ` German Maglione
2022-09-27 17:51 ` Colin Walters
2022-09-27 20:14 ` Stefan Hajnoczi
2022-09-28 8:33 ` Sergio Lopez
2022-09-28 19:28 ` Vivek Goyal
2022-09-29 14:04 ` Colin Walters
2022-09-29 14:10 ` Vivek Goyal
2022-09-29 15:47 ` Colin Walters
2022-09-29 17:03 ` Vivek Goyal
2022-09-30 8:13 ` German Maglione
2022-10-03 22:51 ` Colin Walters
2022-10-05 21:29 ` Vivek Goyal [this message]
2022-09-28 19:26 ` Vivek Goyal
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=Yz33UikaqR4cagWK@redhat.com \
--to=vgoyal@redhat.com \
--cc=gmaglione@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=slp@redhat.com \
--cc=stefanha@redhat.com \
--cc=virtio-fs@redhat.com \
--cc=walters@verbum.org \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).