[Virtio-fs] Securing file handles

[Sergio Lopez]

On Fri, Mar 05, 2021 at 05:22:56PM +0100, Max Reitz wrote:
> == Summary ==
> 
> So, my current position is:
> 
> - Bind mounts don’t help with restricting file handles to the exported
>   directory.
> 
> - A MAC is not very elegant, and we might encounter problems where a
>   file may be moved outside of the shared directory, but remains
>   accessible (because moving a file doesn’t change its handle).
>   (If we consider that a problem.  NFS evidently doesn’t, because
>   without subtree_check, it has absolutely no protection against
>   arbitrary file handles being opened (on the FS where the export
>   resides), so valid file handles always remain valid.)
> 
> - A solution such as NFS’s subtree_check (i.e., storing the file’s
>   parent’s handle in addition to the file’s handle itself, then
>   verifying that the file does still reside in that directory when the
>   handle is opened, and then going up the tree to see whether we can
>   trace it back to the shared directory) is interesting and can perhaps
>   be considered elegant, but it requires iterating the directory the
>   file resides in when it is opened, and it will result in file handles
>   being invalidated whenever a file is moved (outside of its directory).
>   Perhaps also other issues.  In any case, there are reasons why NFS has
>   basically deprecated this.
> 
> Opinions? :)

While the MAC option doesn't look too bad to me, I can't help but feel
that we're working around a kernel (mis)feature, which is something
that's risky and tends to backfire. It also worries me the fact that
we'd need to run virtiofsd with CAP_DAC_READ_SEARCH.

IIUC, we need this to avoid the need to keep an FD open for each entry
that's in the Guest's lookup cache, which is something that's probably
going to become a problem once we have dozens of virtiofsd instances
servicing VMs on the same Host (BTW, this is already a problem on
macOS, where the default *system-wide* NOFILE limit is a little over
10,000).

Perhaps we should try to aim higher and propose some kernel
extensions that would fit better our needs?

Thanks,
Sergio.

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