[Dovecot] I stream read - stale NFS file handle (reboot of server)

[Damon Atkins]

>I'm quite aware of all this. What I was asking for were those "security issues" that you claim to be solved>by randomizing the inode-to-filehandle-relationship on every server reboot.

I have not really wanted to spell it out.

The following is mainly about NFSv2/v3.

Client requests a File Handle for a export file system from mountd, mountd checks its access list, and if the client has access returns a File Handle (for an exported file system). This File Handle can then be used to get directory listing from the top of the export file system.

NFSD gets a File Handle and UID GID information and returns information or data e.g. read a file, get a directory listing based on the File Handle.

Security Issue
File Handles were/are fixed. e.g. something like Major/Minor device number of the disk the file-system was on and inode ie a sort of formula, which has a stable file handle for every file/directory/etc.

The problem (I hope it is still not) is that once you have the file handle for a file or directory you can access any file on a system, exported or not. Because of the formula way of creating file handles makes it possible to guess the file handle for say /, which could be accessed even if it was not exported. Why, because NFSD (and the protocol) assume everyone is nice, and that if you have a file handle then mountd must have given it to you, and hence NFSD just accepts it, so you could read /etc/password, even if /etc was not exported.

NFSD did not re-check access lists for the same things as mountd, if it did check access lists it would slow NFSD down, so some mountd/nfsd implementations made a portion of the file handle random at the time of export, this fixes the security issue of "skipping mountd" or being able to easily "guess" file-handles.

Now (I hope)
CPU performance has increased, and some NFSD talk to mountd to get a list of IP address which are able to present File Handles. i.e. NFDS does some basic IP address checking, in the past it did not check anything that mountd did. These implementations which check the IP for example, may have gone back to a stable file handle between reboots.

I can not give you a list Unix flavours which do random file handles at export (if they did, or if they still do), all I can say is that it's a possible cause of "Stale File Handle" after a reboot, when it is not expected to happen.

OpenSolaris ZFS nfs share presents the same NFS file-handle but NFSD checks with mountd about the client IP address.

Some light reading
http://utcc.utoronto.ca/~cks/space/blog/unix/NFSServerSecurity
http://utcc.utoronto.ca/~cks/space/blog/solaris/SolarisMountdInnards
http://fixunix.com/sgi/110779-stale-nfs-file-handle.html  # second post

This is a lot more detail
http://www.antibozo.net/ogata/webtools/nfs/README.txt
http://www.fsl.cs.sunysb.edu/docs/nfscrack-tr/index.html

If you would like to check the file handle for an export file system 
before and after a reboot you can use the following tool

"nfs is an NFS protocol client package that allows you to test security 
of NFS implementations. It includes a mountd client that enumerates 
exported filesystems and their root filehandles, and an NFS client that 
allows you to perform file transfers, directory listings, object 
renaming, and most other procedures supported by NFS. The NFS client 
resembles an FTP client, and includes command line completion and a 
history mechanism. It supports versions 2 and 3 of the NFS protocol, and 
can use TCP or UDP transport. Both programs compile successfully on 
Linux, FreeBSD, IRIX, and Solaris." 
http://www.antibozo.net/ogata/webtools/index.html

e.g. the file handle for /export/home
./mtq localhost
Connected to mountd server at udp localhost:45743.
/export/home:
     fe9566320838bf750a00030000000000b70100000a00030000000000b7010000

Cheers