Date: 12 Mar 1997 01:19:54 -0000 From: tqbf@char-star.rdist.org To: guido@gvr.win.tue.nl, freebsd-security@freebsd.org Subject: Re: NFS security issue... Message-ID: <19970312011954.205.qmail@char-star.rdist.org> In-Reply-To: <199703111357.OAA27007@gvr.win.tue.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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));
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970312011954.205.qmail>