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. Anyway, forgive the digressions.... --b. -- 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
