From: Vivek Goyal <vgoyal@redhat.com>
To: Colin Walters <walters@verbum.org>
Cc: qemu-devel@nongnu.org, virtio-fs-list <virtio-fs@redhat.com>,
German Maglione <gmaglione@redhat.com>,
Sergio Lopez <slp@redhat.com>
Subject: Re: [Virtio-fs] virtiofsd: Any reason why there's not an "openat2" sandbox mode?
Date: Tue, 27 Sep 2022 12:37:15 -0400 [thread overview]
Message-ID: <YzMmu3xfOtQwuFUx@redhat.com> (raw)
In-Reply-To: <4362261a-c762-4666-84e2-03c9daa6c4d9@www.fastmail.com>
On Fri, Sep 09, 2022 at 05:24:03PM -0400, Colin Walters wrote:
> We previously had a chat here https://lore.kernel.org/all/348d4774-bd5f-4832-bd7e-a21491fdac8d@www.fastmail.com/T/
> around virtiofsd and privileges and the case of trying to run virtiofsd inside an unprivileged (Kubernetes) container.
>
> Right now we're still using 9p, and it has bugs (basically it seems like the 9p inode flushing callback tries to allocate memory to send an RPC, and this causes OOM problems)
> https://github.com/coreos/coreos-assembler/issues/1812
>
> Coming back to this...as of lately in Linux, there's support for strongly isolated filesystem access via openat2():
> https://lwn.net/Articles/796868/
>
> Is there any reason we couldn't do an -o sandbox=openat2 ? This operates without any privileges at all, and should be usable (and secure enough) in our use case.
[ cc virtio-fs-list, german, sergio ]
Hi Colin,
Using openat2(RESOLVE_IN_ROOT) (if kernel is new enough), sounds like a
good idea. We talked about it few times but nobody ever wrote a patch to
implement it.
And it probably makes sense with all the sandboxes (chroot(), namespaces).
I am wondering that it probably should not be a new sandbox mode at all.
It probably should be the default if kernel offers openat2() syscall.
Now all the development has moved to rust virtiofsd.
https://gitlab.com/virtio-fs/virtiofsd
C version of virtiofsd is just seeing small critical fixes.
And rust version allows running unprivileged (inside a user namespace).
German is also working on allowing running unprivileged without
user namespaces but this will not allow arbitrary uid/gid switching.
https://gitlab.com/virtio-fs/virtiofsd/-/merge_requests/136
If one wants to run unprivileged and also do arbitrary uid/gid switching,
then you need to use user namepsaces and map a range of subuid/subgid
into the user namepsace virtiofsd is running in.
If possible, please try to use rust virtiofsd for your situation. Its
already packaged for fedora.
Coming back to original idea of using openat2(), I think we should
probably give it a try in rust virtiofsd and if it works, it should
work across all the sandboxing modes.
Thanks
Vivek
>
> I may try a patch if this sounds OK...
>
next parent reply other threads:[~2022-09-27 16:37 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 ` Vivek Goyal [this message]
2022-09-27 16:57 ` [Virtio-fs] virtiofsd: Any reason why there's not an "openat2" sandbox mode? 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
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=YzMmu3xfOtQwuFUx@redhat.com \
--to=vgoyal@redhat.com \
--cc=gmaglione@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=slp@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).