From owner-freebsd-security  Wed Mar 12 05:06:07 1997
Return-Path: <owner-security>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id FAA09093
          for security-outgoing; Wed, 12 Mar 1997 05:06:07 -0800 (PST)
Received: from gvr.win.tue.nl (root@gvr.win.tue.nl [131.155.210.19])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA08975;
          Wed, 12 Mar 1997 05:03:16 -0800 (PST)
Received: (from guido@localhost) by gvr.win.tue.nl (8.8.5/8.8.2) id OAA19396; Wed, 12 Mar 1997 14:03:00 +0100 (MET)
From: Guido van Rooij <guido@gvr.win.tue.nl>
Message-Id: <199703121303.OAA19396@gvr.win.tue.nl>
Subject: Re: NFS security issue...
In-Reply-To: <19970312011954.205.qmail@char-star.rdist.org> from "tqbf@char-star.rdist.org" at "Mar 12, 97 01:19:54 am"
To: tqbf@enteract.com
Date: Wed, 12 Mar 1997 14:03:00 +0100 (MET)
Cc: freebsd-security@freebsd.org, core@freebsd.org
X-Mailer: ELM [version 2.4ME+ PL28 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-security@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

tqbf@char-star.rdist.org wrote:
> In article <199703111357.OAA27007@gvr.win.tue.nl>, you wrote:
> >I agre. But this is only true for special setups where no systems are involved
> 
> I don't agree with you here. The NFS client code in the kernel even
> acknowledges that there are servers that require NFS requests to come in
> on privileged ports (I believe it's a mount option); I know this is the
> case with Suns.
> 
> Given that the default is to disallow MOUNT service requests coming from
> unprivileged ports, I think there's an inconsistancy happening here.
> What's more, the fact that NFS requests work from unprivileged ports means
> that users with shell accounts on the NFS server can rapidly guess file
> handles over the loopback interface; nothing I can do with packet
> filtering or network partitioning can prevent this.
> 
> Bad. 

I do agree with you. The criticism given was that almost every environment
you also have PC's where you can do the same.

> 
> >made somethig using a syscvtl variable. Perhaps the discussion should
> >be done againb...
> 
> Ok, here's my take. Someone needs to document informally the procedure for
> creating a sysctl int at arbitrary positions in the kernel MIB - the
> sysctl code is a nightmare, and I get the impression that I don't really
> need to know how it works to add more object IDs.
> 
> Once we know how to do that, the change to sys/nfs/nfs_socket.c to check
> privileged ports if "net.inet.nfs.secure" is on is trivial, and can be
> committed and tested immediately. 
> 

Well it is really straightforwrad to do. In fact I had it lying around.

I'll see what I can do.

-Guido

Cc: core