logan@inpnms.UUCP (Jim Logan) (12/23/89)
I received many answers to the wrong question in my first posting, but only a couple of responses when I re-stated my question clearly. That was *my* fault for not being clear in the first posting. Thanks to all who responded to my postings! It seems that NFS under 386/ix *does* have an uncorrected security problem on a network where every user has root access to his/her own UNIX box. When the remote file system is mounted, you can create another person's user ID on your personal machine and access that user's files on the mounted filesystem. orac!pat mentioned that "Secure RPC" from Sun might fix this problem. Does anyone have any more information on this? Here is a summary of the responses that I thought answered my question best: ---------------------------------------------------------------- From: dyer@spdcc.COM (Steve Dyer) Yes, it's true. An amazingly big security hole once you start thinking about it. I thought that Sun had some "secure RPC" feature in recent releases which suffices to limit its impact, but I don't know the details. At Project Athena, we added a small amount of code to our NFS servers such that every uid (not just root) is mapped to "nobody" unless that uid/IP address pair has a "uid mapping structure", a new data structure residing in the NFS server kernel. UID mapping structures are securely installed on the server using a new rpc.mountd RPC call which uses the Kerberos authentication system. We have an application which runs on the client called "attach" which integrates name service, authentication and the mount protocol. From: Yoram Eisenstadter <uunet!cs.columbia.edu!yoram> Under NFS, if somebody is root on a workstation, he does not have root privileges on the server. HOWEVER, if you are root on the workstation, you can easily become any non-root userid on the workstation (use su, or create an arbitrary passwd file entry) and thereby access/modify the files belonging to that uid on the server. The only files that are really protected on the server are those owned by root. Thus, giving workstation users root compromises server security. Now, if you have an environment in which all the users trust each other, this is not much of a problem, since it is difficult for somebody to *accidentally* mess up other people's files when he is root on a workstation; one must deliberately take on the uid of another user in order to do something naughty. From: uunet!genrad.com!jpn (John P. Nelson) No, it isn't. Root on different machines is distinct unless you set up your network to have root be the same everywhere. If "root" on a client creates a file on a server that has NOT been explicitly set up to trust client roots, the file will be owned by the magic userid "nobody" (which maps to user id -2). However, if you have "root" privledge on your local machine, you can then become ANY user which your /etc/login supports. NFS assumes that any user (other than root) on one machine is identical to that user on another machine. From: uunet!gateway.sei.cmu.edu!orac!pat You are misinformed. Having root access to a workstation most explicitly does *not* allow root access to the fileserver (unless the sysadmin of the fileserver sets it up that way, which is *not* the default). There are other security problems, though, which I can't believe RFS wouldn't have. The solution to NFS's security problems is Secure RPC - see if your vendors include an implementation of Sun's Secure RPC with their NFS. From: uunet!auspex!guy (Guy Harris) It depends on what you mean. If you mean "we have enjoyed being able to let people become super-user on the box on their desks without that giving them super-user privileges to access files, etc. on the server", no, it is not true. NFS as distributed by Sun, and as implemented by most vendors, offers user-ID mapping to the extent that user ID 0 from the client gets mapped to a "nobody" user ID on the server, so that you do *not* get root privileges on the server's files by virtue of being root on the client. I think some vendors (e.g., Cray) have implemented full-blown RFS-style user ID mapping as well. ---------------------------------------------------------------- Thanks again guys! Happy holidays! -Jim -- James Logan UUCP: uunet!inpnms!logan Data General Telecommunications Inet: logan%inpnms@uunet.uu.net (301) 590-3069