[Virtio-fs] [RFC] About non-root virtiofsd(1) process

[Stefan Hajnoczi]

On Thu, Jan 14, 2021 at 02:11:28PM +0530, P J P wrote:
>   Hello,
> 
> * Recently I realised that virtiofsd(1) process does not drop its 'root'
>   privileges while sharing host directory tree with a guest VM.
> 
>   Libvirtd(8) generally starts a guest VM with non-root system user (ex. qemu)
>   privileges. If virtiofsd(1) has 'root' privileges, that makes it an
>   accomplice in a potential guest-to-host privilege escalation scenario. Which
>   is not good.
> 
> * IMHO, ideally virtiofsd(1) should not run with 'root' privileges at all.
> 
> * But If it has to, then atleast all default configuration settings must be
>   utmost strict and restrictive as possible. Ex. By default offer only read
>   access to guest VM.

That's not useful. Most users require read-write.

> * Another option is for root virtiofsd(1) process to fork a sub-process which
>   will run with non-root (ex. qemu) system user privileges.
> 
>    - All file I/O operations for sharing a host directory with a guest are
>      performed by the sub-process with non-root system user privileges.
> 
>    - Sub-process shall talk to the parent virtiofsd(1) process only when
>      privileged operation/assistance is required.
> 
>   Ex. https://www.nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/
> 
> ...wdyt?

Please take a look at the current sandboxing implementation in
virtiofsd. It greatly restricts the process. virtiofsd is not just a
process running freely with uid root.

Unlike nginx, virtiofsd needs to perform privileged operations as part
of serving requests. The fundamental issue is that the server must be
able to create, access, and modify files with arbitrary uids/gids.

If you have specific ideas, let's discuss them. We have been following
user namespace and uid/gid mapping/shifting features. They are not
widely available in Linux yet, but once they are it should be possible
to run with root only inside the user namespace (i.e. actually
unprivileged).

There is also an unfinished security document here that we could discuss
further and publish:
https://gitlab.com/virtio-fs/qemu/-/merge_requests/6/diffs?commit_id=718c71fa44f6b92ac27558c903d27935236b08ef

Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/virtio-fs/attachments/20210114/c2c075e2/attachment.sig>