From: A..Andre.Asselin@f1.n100.z60.wlink.nl (A. Andre Asselin)
Newsgroups: comp.os.os2.networking
Subject: NFS Security (or lack thereof)
Date: Tue, 13 Oct 1992 03:32:29 -0100


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!).

Jay,
   Unfortunately, as several other people mentioned, NFS is inherently
insecure in its most popular implementation.  Allow me to explain:
   NFS is based on Sun's RPC protocol (not to be confused with DCE's RPC,
which is different).  The way Sun RPC is implemented, you can have many
different types of authentication.  Currently, two are publicly documented
(as far as I know): AUTH_DES and AUTH_UNIX (there are two others, AUTH_NONE
and AUTH_SHORT which are mainly conviences for programmers-- they provide
no security, so I'll omit them).  AUTH_UNIX is what is used by many many
NFS clients and servers (I'd guess better than 95%).  It's security
consists of passing a UID, a primary GID, and up to 16 additional GIDs.
The theory behind it when it was invented was that since these numbers
were assigned to every user as they logged in (to UNIX), and the system
software inserted them into the outgoing packets, that it would be
difficult to spoof.  Unfortunately, then PC's started getting into the
LAN scene.
   Now, with PC's in the picture, where a user doesn't have to log on,
and any number of people can potentially be sharing the same PC, a
scheme had to be invented for PC's to talk to these UNIX boxes.  Well,
if a PC user is allowed to type in their UID and GID(s) directly, then
they have the ability to spoof the UNIX system into making it believe
they are whoever they want to be.  The only thing the UNIX server can do
is allow access to certain directories from certain computers, but even
that scheme isn't foolproof, because an intelligent PC user can change his
IP address, and BOOM, suddenly the UNIX box thinks your computer is 
actually you boss' computer.  Things get even worse when you start talking
about non-UNIX servers that aren't multiuser and don't have per file
access rights.
   So something had to be done.  What was done was to add PCNFSD, a server
program that runs on the same machine as the NFS server, and who's job is
to dispense a UID/GID pair for a username/password combination (it does
other things as well, but that's irrelevent for this discussion).  So
now, an NFS client on a PC can query the user for his username and password,
pass it along to PCNFSD and retrieve his UID/GID, and then use that combo
in all furthur transactions with the server.  Great in theory, but...
   IBM's first TCP/IP with an NFS client (1.1) didn't use PCNFSD at all.
It directly asked the user for his UID/GID.  To put it nicely, IBM got
many requests to fix this oversite, which I did in early 91.  When version
1.2 shipped, it supported PCNFSD by first checking to see if it was
running on the UNIX host, and if it was, requiring the user to type
a username/password combination (which it passed to PCNFSD and inturn
received a UID/GID).  If PCNFSD wasn't running, it asked the user for
his UID/GID and used those values.  That is the way it currently stands.
   Now, above (a long time ago), I mentioned another authentication
scheme-- AUTH_DES.  To the best of my knowledge, there are few
implementations of NFS that use this option.  Basically, it uses DES
encryption to pass keys back and forth and improve security by
requiring passwords on both ends (I can't really go into detail, because
I never really looked at it much).  This option also goes by the name
secure RPC.  From what I understand, it's pretty slow.
   There is work going on nowadays to try and close the security hole.
There is a preliminary spec. called TNFS (for Trusted NFS) that tries
to address these issues.  Larry mentioned AUTH_KERB-- using Kerberos
to authenticate users.  I think that basically right now we are in a
wait and see mode.  Until one of these new specs. is opened up, praised,
and adopted by many, we're basically stuck with AUTH_UNIX.
   As a side note, two NFS server's I'm familiar with (IBM's VM and MVS
servers) try to solve this problem using a different approach.  In MVS's
case, there is a special program you have to run that you supply with
your MVS username and password, which it passes to the MVS server.  Until
you do so, you are not allowed access to any NFS files.
   With VM, you supply your userid and password as part of the mount
statement, in the portion that gets sent to the server (there are examples
in the IBM User's Guide of these two syntaxes).

Hope this sheds some light on the mystery....
       - Andre Asselin (assela@rpi.edu)


Newsgroups: comp.os.os2.networking