Xref: utzoo comp.protocols.nfs:214 comp.sys.ibm.pc:29458
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!athena.mit.edu!jfc
From: jfc@athena.mit.edu (John F Carr)
Newsgroups: comp.protocols.nfs,comp.sys.ibm.pc
Subject: Re: PCNFS and security
Message-ID: <11714@bloom-beacon.MIT.EDU>
Date: 28 May 89 22:27:50 GMT
References: <2373@daimi.dk> <11668@bloom-beacon.MIT.EDU> <578@eagle_snax.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: jfc@athena.mit.edu (John F Carr)
Organization: Massachusetts Institute of Technology
Lines: 37

In article <578@eagle_snax.UUCP> geoff@hinode.UUCP (Geoff Arnold) writes:
>With current Sun and Sun-derived NFS implementations, you probably
>want to control which hosts can mount sensitive file systems using
>the netgroup mechanism...

>However Per is incorrect when he says that secure RPC won't help. This
>is because with secure RPC you would have to synthesize not just a
>UID/GID but a public-key-encrypted short-lifed "ticket" (to borrow
>the Kerberos term). My understanding of the state of this particular
>art is that the only way to really spoof such schemes is with a combination
>of host impersonation (probably involving gateway subterfuge) and
>messing around with the network time source(s). One PC ain't gonna cut it.

>[After all's said and done, fixing NFS without doing something
>about the other network services is pretty useless. Anyone with
>a Sniffer(tm) or similar network monitor can snarf up all the
>passwords (s)he wants, assuming that telnet or ftp is being used....]

Many of these concerns are addressed by the combination of Kerberos and
Kerberos-authenticated NFS.  Kerberos is used to set up a mapping from a
{client-host,userid} to a {userid,gid...} on the server (most often, this
is the same userid, but it need not be as long as the client kernel is
smart enough not to get confused).  Our NFS servers have an option for each
exported partition to export it in "fascist" mode.  This means that you
can not mount an NFS filesystem if you do not have a uid map set up (the
set of users who can map to the server is stored in a file).  We use this
option to NFS export source code which is not freely distributable (kernel
sources, for example).

This increases the requirment for breaking security, because it is necessary
to impersonate a host that has mappings to the server (as well as the userid
with mappings).   Until there is an encrypted NFS, this is about as good
security as you can get.  I claim that in the general case it is much better
than host-based export restrictions, since the goal is usually to restrict
who can access the filesystem rather than from where they can access it.

--