[Virtio-fs] Securing file handles

[Vivek Goyal]

On Mon, Mar 08, 2021 at 10:54:58AM +0100, Miklos Szeredi wrote:
> Hi,
> 
> Thanks for the good summary.
> 
> Another aspect is what the file handle will be used for:
> 
>  a) allowing server to close O_PATH descriptors any time because they
> can be reconstructed using the file handle

I am probably missing something, so I will ask. To solve problem a)
can we simply store the file handle in lo_inode. (say inode->fh).
and close inode->fd.

And when we need to, do open_by_handle_at(inode->fh). 

Given we already have lo->ino_map redirection, guest can't pass
an arbitrary file handle. So it seems to solve the issue of
arbitrary file handles from guest without MAC stuff and we don't
keep O_PATH fd around.

What am I missing?

Vivek

> 
>  b) allowing NFS export on client, or just name_to_handle_at(2)
> open_by_handle_at(2).
> 
> The requirements are slightly different, since file handles used for
> (a) do not have to persist after a guest reboot (since the VFS cache
> referencing those handles is gone).  While (b) requires persistence
> after a reboot.
> 
> Yet another issue is global CAP_DAC_READ_SEARCH required by the server
> for file handle decode.
> 
> Taking this into account, I think the final solution has to be in the
> host kernel.   E.g. it seems okay to allow user namespace owner to
> decode file handles on filesystems it actually owns.   That would not
> generally help us, though, since virtiofs will want to export root
> owned fs as well.
> 
> Addition of a MAC header to the file handle by name_to_handle_at(2)
> could solve some or all of the above problems.  The question is where
> the key comes from and what the security implications are.
> 
> A per-process (e.g. associated with task->files, generated by the
> kernel on demand and discarded on process exit) key would suffice to
> replace O_PATH descriptors.  In this case the only difference between
> keeping the O_PATH fd open and
> 
>   name_to_handle_at(opathfd, &handle);
>   close(opathfd);
>   opathfd=open_by_handle_at(&handle);
> 
> would be that the resulting fd might point to a disconnected dentry
> and hence would result in incomplete path information under
> /proc/self/fd/.  Need to think hard about whether this has any
> security implications for unprivileged users.
> 
> Adding key management would solve the other aspects, but would also
> possibly open up holes for accessing arbitrary files, so this would
> need to be done carefully.
> 
> Adding subtree checking to the kernel is also a possibility (i.e.
> limit the opened fd to the subtree of the bind mount).   It would have
> the advantage of not resulting in disconnected dentries, but
> disadvantage of not working if the file was moved across directories.
> 
> Thanks,
> Miklos
> 
> _______________________________________________
> Virtio-fs mailing list
> Virtio-fs at redhat.com
> https://listman.redhat.com/mailman/listinfo/virtio-fs