On Wed, Jan 13, 2021 at 02:25:25PM +0000, Trond Myklebust wrote: > BTW: you just 'disclosed the attack method to the public' since > linux-nfs@xxxxxxxxxxxxxxx is a public archived mailing list. However so > far, you've said absolutely nothing that hasn't already been known and > discussed for over 20 years. I dug around a bit and couldn't find the idea of using filehandle guessing plus mountd's following of symlinks to get access to other filesystems. That's kind of interesting. It's not a huge surprise either, and doesn't change our basic recommendation (normally you should only export the roots of filesystems). Which is why I asked the reporter to move the discussion to the public list. I think we could do better here. --b. > > > > > 在 2021年1月13日星期三，Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> 写道： > > > On Wed, 2021-01-13 at 01:13 +0800, 吴异 wrote: > > > > Hello, > > > > > > > > Well,maybe the best method is to prohibit exporting > > > > subdirectiries,and I don't know how difficult it will be. > > > > > > > > > So, there is a discussion of all this in the 'exports' manpage both > > in > > > the description of the 'no_subtree_check' option, and in the > > section on > > > 'Subdirectory Exports'. > > > In particular, the latter section does describe the issue that you > > are > > > raising here: > > > > > > Subdirectory Exports > > > Normally you should only export only the root of a > > filesystem. The NFS > > > server will also allow you to export a subdirectory of a > > filesystem, > > > however, this has drawbacks: > > > > > > First, it may be possible for a malicious user to access > > files on the > > > filesystem outside of the exported subdirectory, by > > guessing filehan‐ > > > dles for those other files. The only way to prevent this > > is by using > > > the no_subtree_check option, which can cause other problems. > > > > > > Second, export options may not be enforced in the way that > > you would > > > expect. For example, the security_label option will not > > work on subdi‐ > > > rectory exports, and if nested subdirectory exports change > > the secu‐ > > > rity_label or sec= options, NFSv4 clients will normally > > see only the > > > options on the parent export. Also, where security options > > differ, a > > > malicious client may use filehandle-guessing attacks to > > access the > > > files from one subdirectory using the options from another. > > > > > > > > > Why do we need to go further than this, when there are clearly also > > a > > > load of scenarios where the clients are all trusted, and the > > security > > > issue is moot? > > > > > > > > > > > > > > Thanks, > > > > > > > > 在 2021年1月13日星期三，Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> 写道： > > > > > On Tue, 2021-01-12 at 10:32 -0500, J. Bruce Fields wrote: > > > > > > On Tue, Jan 12, 2021 at 10:48:00PM +0800, 吴异 wrote: > > > > > > > Telling users how to configure the exported file system in > > the > > > > most > > > > > > > secure > > > > > > > way does > > > > > > > mitigate the problem to some extent, but this does not seem > > to > > > > > > > address the > > > > > > > security risks posed by no_ subtree_ check in the code. In > > my > > > > > > > opinion,when > > > > > > > the generated filehandle does not contain the inode > > information > > > > of > > > > > > > the > > > > > > > parent directory,the nfsd_acceptable function can also > > > > recursively > > > > > > > determine whether the request file exceeds the export path > > > > > > > dentry.Enabling > > > > > > > subtree_check to add parent directory information only > > brings > > > > some > > > > > > > troubles. > > > > > > > > > > > > Filesystems don't necessarily provide us with an efficient > > > > > > way > > to > > > > > > find > > > > > > parent directories from any given file. (And note a single > > file > > > > may > > > > > > have multiple parent directories.) > > > > > > > > > > > > (I do wonder if we could do better in the directory case, > > > > > > though. > > > > We > > > > > > already reconnect directories all the way back up to the > > root.) > > > > > > > > > > > > > I have a bold idea, why not directly remove the file handle > > > > > > > modification in > > > > > > > subtree_check, and then normalize the judgment of whether > > > > > > > dentry > > > > > > > exceeds > > > > > > > the export point directory in nfsd_acceptable (line 38 to > > > > > > > 54 > > in > > > > > > > /fs/nfsd/nfsfh.c) . > > > > > > > > > > > > > > As far as I understand it, the reason why subtree_check is > > not > > > > > > > turned on by > > > > > > > default is that it will cause problems when reading and > > writing > > > > > > > files, > > > > > > > rather than it wastes more time when nfsd_acceptable. > > > > > > > > > > > > > > In short,I think it's open to question whether the security > > of > > > > the > > > > > > > system > > > > > > > depends on the user's complete correct configuration(the > > system > > > > > > > does not > > > > > > > prohibit the export of a subdirectory). > > > > > > > > > > > > > Enabling subtree_check to add parent directoryinformation > > only > > > > > > > brings > > > > > > > some troubles. > > > > > > > > > > > > > > In short,I think it's open to question whether the security > > of > > > > the > > > > > > > system depends on the user's complete correct > > configuration(the > > > > > > > system > > > > > > > does not prohibit the export of a subdirectory). > > > > > > > > > > > > I'd love to replace the export interface by one that > > prohibited > > > > > > subdirectory exports (or at least made it more obvious where > > > > they're > > > > > > being used.) > > > > > > > > > > > > But given the interface we already have, that would be a > > > > disruptive > > > > > > and > > > > > > time-consuming change. > > > > > > > > > > > > Another approach is to add more entropy to filehandles so > > they're > > > > > > harder > > > > > > to guess; see e.g.: > > > > > > > > > > > > > > > > > > https://www.fsl.cs.stonybrook.edu/docs/nfscrack-tr/index.html > > > > > > > > > > > > In the end none of these change the fact that a filehandle > > > > > > has > > an > > > > > > infinite lifetime, so once it's leaked, there's nothing you > > can > > > > do. > > > > > > The > > > > > > authors suggest NFSv4 volatile filehandles as a solution to > > that > > > > > > problem, but I don't think they've thought through the > > obstacles > > > > to > > > > > > making volatile filehandles work. > > > > > > > > > > > > --b. > > > > > > > > > > The point is that there is no good solution to the 'I want to > > > > export a > > > > > subtree of a filesystem' problem, and so it is plainly wrong to > > try > > > > to > > > > > make a default of those solutions, which break the one sane > > > > > case > > of > > > > > exporting the whole filesystem. > > > > > > > > > > Just a reminder that we kicked out subtree_check not only > > because a > > > > > trivial rename of a file breaks the client's ability to perform > > I/O > > > > by > > > > > invalidating the filehandle. In addition, that option causes > > > > filehandle > > > > > aliasing (i.e. multiple filehandles pointing to the same file) > > > > which is > > > > > a major PITA for clients to try to manage for more or less the > > same > > > > > reason that it is a major PITA to try to manage these files > > using > > > > > paths. > > > > > > > > > > The discussion on volatile filehandles in RFC5661 does try to > > > > address > > > > > some of the above issues, but ends up concluding that you need > > to > > > > > introduce POSIX-incompatible restrictions, such as trying to > > > > > ban > > > > > renames and deletions of open files in order to make it work. > > > > > > > > > > None of these compromises are necessary if you export a whole > > > > > filesystem (or a hierarchy of whole filesystems). That's the > > sane > > > > case. > > > > > That's the one that people should default to using. > > > > > > > > > > -- > > > > > Trond Myklebust > > > > > Linux NFS client maintainer, Hammerspace > > > > > trond.myklebust@xxxxxxxxxxxxxxx > > > > > > > > > > > > > > > > > > > > > -- > > > Trond Myklebust > > > CTO, Hammerspace Inc > > > 4984 El Camino Real, Suite 208 > > > Los Altos, CA 94022 > > > > > > www.hammer.space > > > > > > > > -- > Trond Myklebust > CTO, Hammerspace Inc > 4984 El Camino Real, Suite 208 > Los Altos, CA 94022 > > www.hammer.space >
