NFS Security: a summary

[Jim Frost]

In article <43200038 at uicsrd.csrd.uiuc.edu> kai at uicsrd.csrd.uiuc.edu writes:
|I haven't seen anyone mention ANY security problems involving NFS that don't
|require you already have the keys to the kingdom.  Plain unpriviledged joe
|user has exactly the same access on remote file systems as he does on local
|file systems, no more, no less.
|
|OF COURSE if you already have superuser priviledges to system x, it doesn't
|matter if you have NFS access to system y or not, you probably have the power
|to cause damage on other systems.

One thing you might not have thought of.  Consider the case of a Sun
workstation, relatively public (ie user doesn't know the root password
of either the workstation or the server).  How could a user make a
mess of this?  Hot-key the workstation to the firmware, boot single
user.  The 1 to 1 mapping of uid's insures that the user need only
alter the local passwd file to be able to do virtually anything to the
remote filesystem, so long as whatever they're changing isn't
root-only writable.  I haven't looked into NFS group permissions, but
the same type of problem would be even more disastrous if group
permissions carry over NFS (consider group wheel on most systems).
Luckily it's a little more complicated than this to actually become
root on the remote system, but if you can be anyone else....

|On our Sequent systems (DYNIX V3) with NFS, it IS possible to mount file
|systems with the option to ignore the setuid bit on files.  I would like to
|know if this is an NFS, Sequent, 4.2 BSD or 4.3 BSD feature.

It's not an issue.  You don't mount disks you don't trust.  In the
other direction, someone using a local setuid program to try to futz
with an NFS connection to a remote disk, the root uid doesn't carry so
you can't hurt anything.  Or at least it's a little harder.

|Patrick Wolfe  (pwolfe at kai.com, kailand!pwolfe)

jim frost
adt!madd at bu-it.bu.edu