(I'm breaking my PTO rules for this, because writing this driver was a very intense experience for me, and it's not like I can put it out of my mind from a Friday to a Saturday, after waking with it and going to bed with it for three weeks... I just couldn't resist checking the mailing list archive, and then logging in.)
On 12/18/20 19:13, Dr. David Alan Gilbert wrote: > * Ard Biesheuvel ([email protected]) wrote: >> On 12/16/20 10:10 PM, Laszlo Ersek wrote: [...] >>> +# Permission Model of this driver: >>> +# >>> +# Regardless of the UID and GID values this driver send in the FUSE request >>> +# header, the daemon (that is, the Virtio Filesystem device) always acts >>> with >>> +# root privileges on the host side. The only time the daemon considers >>> said UID >>> +# and GID fields is when creating a new file or directory. Thus, the guest >>> +# driver cannot rely on the host for enforcing any file mode permissions, >>> +# regardless of the "personality" that the guest driver poses as, because >>> +# "root" on the host side ignores all file mode bits. >>> +# >>> +# Therefore the guest driver has to do its own permission checking, and >>> use the >>> +# host-side file mode bits only as a kind of "metadata storage" or >>> "reminder" >>> +# -- hopefully in a way that makes some sense on the host side too. >>> +# >> >> Can you please explain why this is safe? Or should virtio-fs only be >> used with guests that can be trusted with root privileges on the host? > > The daemon sandboxes itself and generally you only expose a private area > of a filesystem to the guest; i.e. a per-guest rootfs or temporary or > whatever. Stefan wrote a document about this: [PULL 059/111] virtiofsd: add security guide document https://lists.gnu.org/archive/html/qemu-devel/2020-01/msg05464.html some excerpts: > +Security Requirements > +===================== > +Guests have root access to the shared directory. This is necessary for root > +file systems on virtio-fs and similar use cases. and > +Deployment Best Practices > +========================= > +The shared directory should be a separate file system so that untrusted > guests > +cannot cause a denial-of-service by using up all available inodes or > exhausting > +free space. > + > +If the shared directory is also accessible from a host mount namespace, it is > +recommended to keep a parent directory with rwx------ permissions so that > other > +users on the host are unable to access any setuid executables or device nodes > +in the shared directory. The `nosuid` and `nodev` mount options can also be > +used to prevent this issue. This document, originally proposed as "docs/tools/virtiofsd-security.rst", doesn't seem to have made it to the QEMU tree yet; it was put aside while a good location for it would be figured out. See this subthread under the v1 PULL: https://lists.gnu.org/archive/html/qemu-devel/2020-01/msg05733.html and then see the PULL v2 changelog -- "drop the docs while we discuss where they should live": https://lists.gnu.org/archive/html/qemu-devel/2020-01/msg05780.html (If there have been developments in this area since then, I'm not aware of them; sorry if my info on the docs' location is out-of-date.) Thanks! Laszlo _______________________________________________ Virtio-fs mailing list [email protected] https://www.redhat.com/mailman/listinfo/virtio-fs
