"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. 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. >> So the basic rule I think is "don't allow lookup-by-filehandle (or NFS >> export) on part of a filesystem unless you'd be willing to allow it on >> the whole thing". > > (So in case it wasn't clear: ACK to just ignoring this, I don't think > your (otherwise interesting) observations point to anything that needs > fixing in the lookup-by-filehandle case.) Thanks for looking into this. It helps to know that someone who knows the history of what happens with filehandles has looked at this. 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
