From owner-freebsd-security Tue Mar 11 17:28:38 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id RAA29191 for security-outgoing; Tue, 11 Mar 1997 17:28:38 -0800 (PST) Received: from mail.crl.com (mail.crl.com [165.113.1.22]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id RAA29173 for ; Tue, 11 Mar 1997 17:28:33 -0800 (PST) From: tqbf@char-star.rdist.org Received: from char-star.rdist.org by mail.crl.com with SMTP id AA05575 (5.65c/IDA-1.5 for ); Tue, 11 Mar 1997 17:20:40 -0800 Received: (qmail 206 invoked by uid 1001); 12 Mar 1997 01:19:54 -0000 Date: 12 Mar 1997 01:19:54 -0000 Message-Id: <19970312011954.205.qmail@char-star.rdist.org> To: guido@gvr.win.tue.nl, freebsd-security@freebsd.org Subject: Re: NFS security issue... In-Reply-To: <199703111357.OAA27007@gvr.win.tue.nl> Reply-To: tqbf@enteract.com Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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. >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. This seems fairly urgent to me. Can I get some information about this? Thanks! -- ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- exit(main(kfp->kargc, argv, environ));