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
