NFS Security: a summary

[Eirik Fuller]

In article <43200038 at uicsrd.csrd.uiuc.edu> kai at uicsrd.csrd.uiuc.edu writes:
>
> ...
>
>As I understand it (as systems administrator for multiple Sequent hosts
>sharing disks between them using NFS), NFS requires that uid numbers be
>identical on client and server (for example, user 900 is the same person on
>both systems).  Typically in environments where this is true, the server
>"trusts" the client (via /etc/hosts.equiv), which applies to rlogin and rsh
>commands too.  Even if you don't have NFS, if you're root, you can su to
>another user and simply rlogin in to other hosts and wreak havok.  NFS
>doesn't provide any additional hazard.

This is valid in some environments, and in fact clears up some of my
confusion about why NFS was implemented the way it was, but it misses
the point entirely about what's wrong with NFS.

> ...
>.  If access to the superuser account is your problem, then NFS
>isn't any additional threat.  If you can't trust a remote system
>administrator, then your system probably shouldn't 'trust' their system, and
>you shouldn't export file systems to them.
>

This statement pretty much summarizes what's wrong with NFS.  With
.rhosts, individual users can give away their own files.  With NFS,
only an adminstrator can give away files, and only an entire file
system at a time (I'm aware of exceptions to this, but they weren't
part of the original NFS design).

Todd Brunhoff's RFS at least had the sense to use the .rhosts mechanism
so that users could give away their own files.  I realize it has
problems of its own, but in this one respect it makes much more sense
in the usual BSD environment than the NFS mechanism.  I suspect the
NFS approach is better performace-wise, but nonetheless it is far
worse than rsh from a security viewpoint.