Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!ncar!tank!uxc!uxc.cso.uiuc.edu!uicsrd.csrd.uiuc.edu!kai
From: kai@uicsrd.csrd.uiuc.edu
Newsgroups: comp.unix.wizards
Subject: Re: NFS Security:  a summary
Message-ID: <43200038@uicsrd.csrd.uiuc.edu>
Date: 8 Sep 88 06:18:00 GMT
References: <153@leibniz.UUCP>
Lines: 50
Nf-ID: #R:leibniz.UUCP:153:uicsrd.csrd.uiuc.edu:43200038:000:3041
Nf-From: uicsrd.csrd.uiuc.edu!kai    Sep  8 01:18:00 1988


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.  If you want to discuss the standard
hollyweird horror movie theme as applied to systems administration, read on:

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.  And in environments where hosts don't
trust each other, root can search for ~user/.netrc files or special aliases
and scripts to get remote system access.

However, this is arguing a pretty silly point.  If you're a superuser, you
probably aren't the type of person that intentionally tries to cause damage
to systems.  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.

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.

In general, I like NFS.  I've recovered disk space now that user's can share
a home directory between all systems, and groups that needed just a medium
amount space on multiple systems can share one large partition between
systems, instead of having one medium one on each system.  Now, when the
system I'm using is being crushed by some other user, affecting my work, I
just login to another system that isn't so heavily loaded, and continue my
work.  We don't need to keep separate source code directories, timesheet
information, event calendars, etc. on each system anymore.

The only problems I've had with NFS deal with some parallel programs when
executables reside on remote file systems, performance problems versus local
file systems, Sun's PC/NFS not allowing access to all the user's groups on
the unix system, and the inevitible argument about whether hard or soft
mounted file systems are better (we use soft - I hate it when 'df' hangs
because a system is down for backups, and we don't have any critical database
operations that simply MUST wait for the remote system to respond).

Patrick Wolfe  (pwolfe@kai.com, kailand!pwolfe)