Re: [Virtio-fs] Securing file handles

[Stefan Hajnoczi <stefanha@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3041 bytes --]

On Mon, Mar 08, 2021 at 10:06:50AM +0100, Sergio Lopez wrote:
> 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?

Another option is to aim lower than everything that has been discussed
here:

Only support handle operations when the shared directory is the root of
a file system. That way the security issues are mostly eliminated.

The rationale is that most applications don't need file handles. If you
require file handles then you'll need to go through the effort of
creating a dedicated file system for the shared directory. For all other
cases, we'll disable file handle operations and not worry about it.

There is one security issue I can think of: if the host administrator
creates a mount inside the shared directory intended to "hide" access to
the files beneath, then I guess file handles could still access those
files.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]