[comp.protocols.nfs] PCNFS Security Problems - Questions

92disanto@gsb-yen.stanford.edu (05/29/91)

I would like to know about security problems using NFS on a PC.
I'm building an application that needs to download and upload user
files on a UNIX host to and from a personal computer.  At first
I thought that I could rely on NFS to do this for me, but I am finding
out that site administrators seem to think that NFS has too many
security problems to allow its use from a PC.  Can someone summarize
what these problems are?  As I (somewhat) understand it, the standard
NFS protocol allows an entire volume to be mounted, and it has no
way to enforce user-level restrictions on access to files on that volume.
Is this correct?  Is there a way to build an application so that it
could use NFS in a secure fashion without exposing an installation
to security risks?

Send response (or copy of) to "simpsons@leland.stanford.edu".  Thanks.

Jim.
 

rbraun@spdcc.COM (Rich Braun) (05/29/91)

ps3@ph3hp840.physik.uni-stuttgart.de (ps-Gruppe) writes:
>I think that using PCNFS is not a security problem, because the PCNFSD
>( the daemon for PCNFS on your workstation) queries for your password, when
>mounting NFS.

The level of security probably depends mainly on the sophistication of
your users.  If you grant physical access to the Ethernet cable itself
to a PC user, a sophisticated PC user should be able to get access to
any file on the network.  Period.

At the very least, a user could program the PC to "sniff" the network
for packets containing passwords, as they go by.  At a greater level,
the user could program it to masquerade as another system on the network
and give out fake user IDs in RPC calls for file access.

Neither Ethernet nor NFS were designed for high security.  Unix systems
typically don't allow direct access to the IP packet interface, so a
user logging into a Unix system probably can't write a program which can
masquerade as something else.  But a DOS user could do this easily enough.

If you want high security, make sure the Ethernet can be physically
accessed only by systems which rigidly control access to the IP network
layer.  Or use a different system for authentication (MIT's kerberos, etc).

We have the U.S. government to thank for this situation:  data encryption
would be much further along were it not for the NSA's desire to quash
any truly useful encryption scheme, in the interest of preventing spies
from getting cheap access to mathematically superior coding algorithms.
We can also thank Big Business, which hasn't yet shown much interest in
creating secure networks.  But don't blame the developers of NFS or of
the PC, who never had "high security" in mind to begin with.

-rich

ps3@ph3hp840.physik.uni-stuttgart.de (ps-Gruppe) (05/30/91)

In article <1991May28.180655.1@gsb-yen.stanford.edu> 92disanto@gsb-yen.stanford.edu writes:  
>
>I would like to know about security problems using NFS on a PC.

I do not have much experience with NFS, because we are just starting with
this things. If I am wrong, Please correct me.

I think that using PCNFS is not a security problem, because the PCNFSD
( the daemon for PCNFS on your workstation) queries for your password, when
mounting NFS. So you cannot do anything, you colud not do when logging in.

In normal NFS (with workstations) there is no password. The server just takes
your user-id to determine, what you are allowed to do. This means: When a
file-system is exported to the whole world, you can take your workstation,
create a user with an user-id, which exists on the server and then you can
do the same things like the real user without knowing the password of this
user. So you should filesystems only to computers you know or you should
restrict the user for an export to the whole world. (For example only anonymous
when exporting to the world and giving only small capabilities to the user
anonymous).

Regards
  Thomas Stuempfig

==============================================================================
Thomas Stuempfig             |  stuempfig@physik.uni-stuttgart.de
Pikosekunden-Labor           |  ps3@ph3hp840.physik.uni-stuttgart.de
3. Physikalisches Institut   |================================================
Uni Stuttgart                |  ocac@ds0rus1i.bitnet
==============================================================================