[vpn] Re: vpn nfs (fwd)

dgillett at deepforest.org dgillett at deepforest.org
Mon Oct 22 21:11:57 EDT 2001

  Thank you for the clarification, which helps considerably.

  It appears to me that your internal machines share security/account 
info (NIS?), so that any internal machine can mount volumes from the 
NFS server and will locally enforce the access permissions for each 
user account.
  But because remote users are typically root on their remote 
machines, they will have all access to any mounted NFS volumes, as if 
they were root on an internal machine.
  Okay so far?

  I would be surprised and disappointed if there is not some way to 
configure your NFS server such that it will only allow remote 
machines to mount data subject to local enforcement of the shared 
account structure.

  However, in the absense of knowledge of such a provision, the other 
possibility that springs to mind is to secure your network so that 
remote machines are not allowed to mount NFS shares directly.  Force 
remote users to connect to an internal server (perhaps using 
SSH?[*]), such as the one they would use if they were on-site, which 
does enforce the network security account structure, and which in 
turn serves as the NFS client.

[*] Note that SSH alone provides a shell connection, and this is not 
usually considered a VPN unless you run something like PPP over that 
to provide a transport layer.

David Gillett

On 23 Oct 2001, at 0:11, AlanCB wrote:

Hash: SHA1

Thankyou for your response(s)
let me clarify the situation:

In our network we have several hundred unix boxes all connected to our nfs
server. These boxes are ours of course, only the sysadmins are root. No
box is behind a firewall or in a vpn, all have a publicly assigned ip.
Being a university, we have assistants, professors and doctorates who
bring in their own laptops and need a net connection. Now I'm sure you
know the dangers there are when someone has root on a box and can connect
to our nfs server...enough said there. The further dangers of having root
on our network which doesnt belong to us dont even need to be mentioned.
Hence my idea of a vpn, with say a network like 192.168.1/24
They can do what they want there with root, however they should still be
allowed to connect to the nfs/internet.
Here's where my problem lies - I can't set two different types of perms on
our nfs server for the same user. When he's using one of our boxes again
and his notebook is at home, he needs his user dir and software on the
So here's my (confusing) situation:

user with notebook, ip: goes over vpn gateway
which has a second interface ( to our nfs. The nfs allows to do anything any other normal box can. The vpn gateway
should be able to decide that user from only has r+w
perms to his user dir on the nfs and r perms to our software directory on
the nfs.

Is this somehow possible or is there a more simple method for people with
their own notebooks in our network ?
a Virtual Private Network to me is one which (in our case) has privately
assigned ip's and has a gateway which masquerades and is a firewall.
Gshield (with some work of my own) easily does this. The only problem(s) I
have are outlined above.

Thankyou for you swift replies from today and I look forward to any
response !


On Mon, 22 Oct 2001, Kurt Seifried wrote:

> > > My problem:
> > > The users should have r+w perms on their own directories only, and
> > > r only on the software dir. Instead of setting multiple permissions
> > > on the NFS server, which is basically impossible, I need a way of
> > > setting permissions on my vpn gateway. With your experience, is
> > > there a tool or method you know of which enables this ? A blunt
> > > question, I know, however I'd much appreciate your help.
> What makes them less impossible to implement on the gateway? Let's assume
> for a minute that an NFS proxy exists that will let you enforce permissions.
> Several problems come to mind:
> 1) anyone circumventing the VPN (i.e. coming from inside) will be able to
> run wild through the NFS server. oops.
> 2) obsfuscation attacks, encoding of data, using things like cd
> "/././././././../foo/bar/../etc/" etc etc. HTTP is hard enough to monitor
> and I don't imagine NFS is any easier
> 3) encryption of nfs services/login. awwww crap.
> 4) integrating authentication systems/etc.
> Perhaps you should consider a different file sharing protocol/system then
> NFS if permissions are that much of an issue. CODA/AFS/SMB/Novell/etc come
> to mind.
> To draw a parallel: Every Microsoft person I know says you should set your
> directory share permissions to everyone:full control and use NTFS
> permissions to enforce access.
> Kurt Seifried, kurt at seifried.org
> A15B BEE5 B391 B9AD B0EF
> AEB0 AD63 0B4E AD56 E574
> http://www.seifried.org/security/

Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org


VPN is sponsored by SecurityFocus.com

More information about the VPN mailing list