On Wed, 2021-01-13 at 17:00 +0800, 吴异 wrote: > Linux reference manual does describe the risk of exporting > subdirectories of a file system,but I think there are some omissions. > > /fs on /dev/sda1 > export /fs/nfs > > I can easily guess the handle of /fs,and then use it to remove the > export point /nfs by a symlink,which is pointing to files in other > file systems,e.g. "/" on /dev/sdb,it just like inserting a back door > into the server.And then when nfsd service restart,I can mount to "/" > ,this breaks file system isolation. > > My question is whether Linux has made users fully aware of the > security risks posed by subdirectories.In other words,how many people > will be attacked with the nfsd when attack method is disclosed to the > public? The above is precisely what the manpage warns you about and tells you not to do as an administrator of a server. 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. > > 在 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
