"J. Bruce Fields" <bfields@xxxxxxxxxxxx> writes: > On Mon, Aug 31, 2015 at 04:17:28PM -0500, Eric W. Biederman wrote: >> "J. Bruce Fields" <bfields@xxxxxxxxxxxx> writes: >> >> > On Fri, Aug 28, 2015 at 03:43:02PM -0400, J. Bruce Fields wrote: >> >> On Wed, Aug 05, 2015 at 11:28:55AM -0500, Eric W. Biederman wrote: >> >> > The file handle reconstitution code can certainly be affected by all of >> >> > this. Given that it is an failure if reconnect_path can't reconnect the >> >> > path of a file handle. I think it can reasonably considered an error in >> >> > all cases if that path is outside of an exported bind mount, but I don't >> >> > know that area particularly well. The solution might just be don't >> >> > export file handles from bind mounts. >> >> >> >> I don't think there's any new cause for concern here. >> >> >> >> I'd quibble with the language "don't export filehandles", *if* by that >> >> you mean "don't tell allow anyone to know filehandles". They're >> >> guessable, so keeping them secret doesn't guarantee much security. >> >> >> >> The dangerous operation is open_by_handle, and people need to understand >> >> that if you allow someone to call that then you're effectively giving >> >> access to the whole filesystem. That's always been true. (We don't >> >> really have an efficient way to determine if a non-directory is in a >> >> given subtree anyway.) >> >> >> >> >> >> Such filehandle-guessing attacks on NFS have long been well-understood. >> >> NOSUBTREECHECK can prevent them but causes other problems, so isn't the >> >> default. >> >> Interesting. I guess it makes sense that filehandles can be guessed. I >> wonder if a crypto variant that is resistant to plain text attacks would >> be a practical defense. > > People have considered it. I don't think it would be hard: just > generate some permanent server secret and use it to encrypt all > filehandles (and decrypt them again when looking them up). > > Some of the reasons I don't think it's been done: > > - Well, it's work, and nobody's really felt that strongly about > it. > > - It's usually not that hard to create another filesystem when > you need a real security boundary. > > - Filehandles are forever. But it's hard to keep secrets > forever, especially when they have to be transmitted over the > network a lot. (In more detail: client applications can hold > long-lived references to filesystem objects through open file > descriptors or current working directories. They expect those > to keep working even over server reboots. We don't even know > about those references. So any filehandle we give out could > be looked up at any time in the future. The only case where > we consider it acceptable to return ESTALE is when the > object's actually gone.) > >> We do have d_ancestor/is_subdir that is a compartively efficient way to >> see if a dentry is in a given subtree. As it does not need to perform >> the permission checks I believe it would be some cheaper than the >> current nfs subtree check code. I don't know if that would avoid the >> known problem with the subtree check code. Nor do I know if it would be >> cheap enough to use for every nfsd operation when a file handle is >> received. > > That would solve the problem for directories, but not for files. For > non-directories we'd need special support from the filesystem (since at > the time we look up the filehandle the parent(s) may not be in the > dcache yet). Steps to check subtree membership would be roughly (number > of hardlinks) * (average depth). I think it's probably not worth it. If viewed that way you are probably right. I was simply thinking about using the existing subtree check without the inode_permission test. Which works at the cost of a readdir to reconnect an inode to a directory. I had not noticed the readdir before. So I admit it does not sound like something that is a particularly speedy way to go. > Anyway, forgive the digressions.... No problem. Thank you for the discussion. This has if nothing else allowed me to understand this from a real world perspective, and in particular allows me to understand which permission checks would be necessary to safely allow file handles in a user namespace (if we ever decide it is safe to allow that). In short if you did not mount the filesystem you better not be nfs exporting the filesystem, or parts of the filesystem, or be allowed to use file handle access to the filesystem. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
