From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: <34a26a91-c73d-18cb-95ad-9b2c6192091c@redhat.com> In-Reply-To: <34a26a91-c73d-18cb-95ad-9b2c6192091c@redhat.com> From: Miklos Szeredi Date: Mon, 8 Mar 2021 10:54:58 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" 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: Max Reitz Cc: virtio-fs-list 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 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