Date: Wed, 22 Feb 95 11:05:16 MST From: terry@cs.weber.edu (Terry Lambert) To: dfr@render.com (Doug Rabson) Cc: current@FreeBSD.org Subject: Re: mountd changes Message-ID: <9502221805.AA24450@cs.weber.edu> In-Reply-To: <Pine.BSF.3.91.950222133611.8409A-100000@minnow.render.com> from "Doug Rabson" at Feb 22, 95 01:40:32 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I have some changes here for mountd which do two things: > > (1) Stop it from moaning when more than one mountpoint in a given > filesystem is exported. > > (2) Allow mounts of directories which have an exported initial > segment. > > I am wondering whether to commit these. (1) is probably safe but (2) > might be a security risk. Comments? The reason for #1 is that server caching (not in the server's FS, but in the server code itself) could result in a bad interaction where bogus data got blown to disk as a result of write requests to the same file for multiple clients. This is because cache coherency is not maintained between exported mount points, and this is mostly because the NFS server isn't a multithreaded instead of a multiprocess implementation using only kernel threads (which we don't have any of). So it's a design limitation for *BSD, not a protocol limitation for NFS. #2 is a security problem because mount requests are made as root. I believe it was SunOS 4.1.3_U2 that addressed this by disallowing it in the Sun NFS implementation. The exact failure is that unless you allow a hosts root in, it will not allow an iteration of the descending directories to be made as "nobody". I agree that this is disasterous for AMD based dataless workstations. The correct response is to allow their root user in as root. The reason for the change was that NFS cookies can be manufactured from an insecure host inside the secure zone and not have to traverse intermediate security restrictions to get at terminal file system objects. Basically, this means that you can hack on file that you would not be able to get to and which live in protected directories if you know their names -- and you can get the names from snooping the wire traffic of authorized users. I believe there was a CERT advisory recommending this lockdown. There is a difference in implementation, which could be considered bad. The security update as shipped by Sun added a debug statement to set a kernel flag into the rc files. Unlike the *BSD soloution, this is administrator switchable. The *BSD soloution ought to be switchable as well. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9502221805.AA24450>