From: Larry.Backman@f1.n100.z60.wlink.nl (Larry Backman)
Newsgroups: comp.os.os2.networking
Subject: NFS Security (or lack thereof)
Date: Mon, 12 Oct 1992 20:14:10 -0100

Organization: FTP Software, Inc., Wakefield, MA

In article <1992Oct11.090253.21863@netcom.com> badboy@netcom.com (Jay Keller) writes:

 >> The problem:  my OS/2 users are in danger of getting kicked off the net 
 >> because of how easily any of them can defeat the security of NFS and
 >> potentially do mischief in the Unix world.  All an OS/2 user with IBM TCP/IP
 >> has to do is set the UID and GID to anything he or she wants it to be, and 
 >> then mount anywhere in the Unix file system with read and write privileges.
 >> The DOS users, who now run the UID/GID flavor of FTP, Inc.'s IDRIVE, can
 >> do the same thing.  Since a lot of these people do have accounts on the
 >> Sun side, they can read /etc/passwd to get valid UID/GID pairs and easily
 >> get access to just about anything that can be had without root password
 >> (at least that is what it seems like to me, please tell me I'm wrong!).
 >> 
 >> All it will take is one malicious disgruntled employee to abuse this system
 >> and I can be sure that the DOS and OS/2 users will be kicked right off the
 >> network..
 >> 
 >> So, what's the story?  Is NFS really so bogus?  Can we do something to
 >> close this hole?  Is it not the NFS server's problem, even though they want
 >> to blame the OS/2 and DOS clients?  Are these dumb questions?
 >> 
NFS stands for No File Security :-).  It was really designed with Unix
workstations in mind; and the with the concept that a person with access
to NFS commands & files (mount, /etc/passwd, etc.) had already passed
some sort of authentication, i.e. had logged into a UNIX host.  With this
security paradigm, NFS RPC's typically contain a clear-text hostname &
a UID/GID combination of the user who wishes access to something from that 
host.  The server loosely authenticates access based on the hostname
having access to the appropriately exported filesystem, and the UID/GID
of that user having access to the file in question.

This paradigm clearly falls apart with PC's which don't have either a
concept of login, or a UID/GID.  There is a loose sort of authentication
provided by PCNFSD, a server which runs in parallel with the NFSD server
and provides a cheap mapping of a PC user's username password to a UID/GID
which the PC user can then use in future NFS RPC's.  Most PC NFS vendors
support PCNFSD security; IBM does not at this point in time.

An alternative to PCNFSD is for the PC client to somehow allow the user
to specify a UID/GID combination; this is what IBM does with their OS/2
product with a cleartext UID/GID pair located in one of their
etc files.  Not to cast stones without admitting blame; FTP's NFS client
is only slightly better.  While we suppport PCNFSD security we also support
local or Unix style security. We have a local passwd file with a DES 
encrypted passwd and a UID/GID combo. associated with each user entry.  If 
the user passes local authentication, that UID/GID is then used in all future
RPC's.  There are security problems with this approach....

The hope of the future for NFS security with PC's lies in Kerberos 
authentication.  With this scheme a PC authenticates itself via Kerberos
with the NFS server.  Unfortunately at the current time there are two dualing
Kerberos NFS implementations, the MIT one, which was designed solely for MIT;
and the one Sun has put in Solaris 2.0, which at this time is undocumented.

So; to summarize; your IBM NFS clients are extermely insecure; FTP's or another
vendors clients would be slightly better using PCNFSD, buit by no means can 
be considered secure.

Larry Backman
FTP Software

Newsgroups: comp.os.os2.networking