Grant Beattie <grant@grunta.com> writes:

> > Any Unix vendor who claims otherwise about their NFS implementation is
> > misrepresenting themselves.
> 
> Are you sure? Am I missing something?
> 
> I've been doing NFS on Solaris for years and have been able to use
> different options per export for as long as I remember.

In reality, an attacker could access any of the exported filesystems
with options permitted by the least restrictive of the exports.

The NFSv2 spec is RFC 1094, NFSv3 is 1813, and I'm ignoring NFSv4
because it doesn't really exist in the market yet. The details are in
there.

The key is that the server has no knowledge (and because of the
statelessness more-or-less required by the protocol, can not keep
knowledge) of what files it has returned handles for. Handles are
constructed by the server from the file's inode number and a little
bit of extra information. The server, when presented with a handle,
can really only verify that it is on the correct filesystem - it can
not check its location in the directory tree to verify that it is
permitted to be accessed that way.

As an example, suppose I have a server with a filesystem /u1,
exporting /u1/exportA to host A and /u1/exportB to host B
read-write.

Host A accesses /u1/exportA/read-only-file and obtains a handle H1 for
the file. Through some amount of cleverness (not directly exposed by
most NFS clients but nevertheless possible), the handle is
communicated to host B. Host B can then present the handle to the
server in a write operation and write to /u1/exportA/read-only-file,
because all it can determine is "Host B is allowed to write to
/u1". It has no idea whether H1 refers to a file under /u1/exportA,
/u1/exportB, or somewhere else entirely.

> I would have considered it also to be broken, had it not allowed such
> configurations to work.

Rather, consider that Solaris has been misleading you about the
security provided by NFS. Now, if you're depending on NFS for security
anyway, I have a lovely bridge in downtown Tuscon at an attractive
price.... 

        - Nathan