From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 8 Mar 2021 17:03:31 -0500 From: Vivek Goyal Message-ID: <20210308220331.GB29382@redhat.com> References: <34a26a91-c73d-18cb-95ad-9b2c6192091c@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Virtio-fs] Securing file handles List-Id: Development discussions about virtio-fs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Miklos Szeredi Cc: virtio-fs-list , Max Reitz 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@redhat.com > https://listman.redhat.com/mailman/listinfo/virtio-fs