logan@inpnms.UUCP (Jim Logan) (12/15/89)
We all have 386's on our desks running RFS and have enjoyed having root access to our machines, but not on the server. From what we have read, this is not possible under NFS. Is this true? We are in the process of changing over to NFS from RFS under 386/ix in order to use the large disks on our MV 40000 running DG/UX. Is seems that the only way to prevent root access on the server under NFS is by appointing one person as the administrator. It doesn't make much sense to have one person responsible for an entire network of 386's. He would have to be responsible for changing the mode of files, killing processes, etc. No one around here wants grunt work like this. Is this really a security issue, or are we misinformed? Is there a solution? ADVthanksANCE, -Jim -- James Logan UUCP: uunet!inpnms!logan Data General Telecommunications Inet: logan%inpnms@uunet.uu.net (301) 590-3069
bitbug@lonewolf.sun.com (James Buster) (12/15/89)
In article <218@inpnms.UUCP> logan@inpnms.UUCP (Jim Logan) writes: > We all have 386's on our desks running RFS and have enjoyed > having root access to our machines, but not on the server. From > what we have read, this is not possible under NFS. Is this true? > > We are in the process of changing over to NFS from RFS under > 386/ix in order to use the large disks on our MV 40000 running > DG/UX. > > Is seems that the only way to prevent root access on the server > under NFS is by appointing one person as the administrator. It > doesn't make much sense to have one person responsible for an > entire network of 386's. He would have to be responsible for > changing the mode of files, killing processes, etc. No one > around here wants grunt work like this. > > Is this really a security issue, or are we misinformed? Is > there a solution? I'm not sure what question you are asking? Do you mean, does a root user on the client have normal root file access permissions on file systems mounted from the server, or is a root user on the client able to log into the server as root? By default in NFS, a user with uid 0 is mapped to uid -2 when check permissions on NFS partitions. This means that a user with uid 0 cannot normally affect anything on an NFS mounted partition. This feature may be disabled. NFS has nothing to do with a user's ability to log in as root on a server. -- --------------------------------------------------------------------- James Buster (Domain) bitbug@lonewolf.ebay.sun.com Mad Hacker Extraordinaire (UUCP) ...!sun.com!lonewolf!bitbug ---------------------------------------------------------------------
logan@inpnms.UUCP (Jim Logan) (12/16/89)
In article <BITBUG.89Dec14220256@lonewolf.sun.com> bitbug@lonewolf.sun.com (James Buster) writes: # In article <218@inpnms.UUCP> logan@inpnms.UUCP (Jim Logan) writes: # > We all have 386's on our desks running RFS and have enjoyed # > having root access to our machines, but not on the server. From # > what we have read, this is not possible under NFS. Is this true? # > # > We are in the process of changing over to NFS from RFS under # > 386/ix in order to use the large disks on our MV 40000 running # > DG/UX. # > # > Is seems that the only way to prevent root access on the server # > under NFS is by appointing one person as the administrator. It # > doesn't make much sense to have one person responsible for an # > entire network of 386's. He would have to be responsible for # > changing the mode of files, killing processes, etc. No one # > around here wants grunt work like this. # > # > Is this really a security issue, or are we misinformed? Is # > there a solution? # # I'm not sure what question you are asking? Do you mean, # does a root user on the client have normal root file access # permissions on file systems mounted from the server, or is # a root user on the client able to log into the server as root? No, I was a bit too vague in my original posting. Let me rephrase in more detail. Given a server with user IDs 101, 102, and 103, and a client having only UID 101, anyone with root access on the client can access files owned by UIDs 102 and 103. This is a big security hole if it is true. As I understand it, there is no way to have a user on the server that is unmappable on a client. For instance, we have the user "scm" (source-code management) on the host that owns the files that we release. These files cannot (and should not) be modified in any way by a user on a client, since "scm" maps to a bogus UID on a client under RFS. We simply want the same, or equivalent, functionality from NFS. Can it be done? -- James Logan UUCP: uunet!inpnms!logan Data General Telecommunications Inet: logan%inpnms@uunet.uu.net (301) 590-3069
envbvs@epb2.lbl.gov (Brian V. Smith) (12/16/89)
In article <218@inpnms.UUCP>, logan@inpnms.UUCP (Jim Logan) writes:
< We all have 386's on our desks running RFS and have enjoyed
< having root access to our machines, but not on the server. From
< what we have read, this is not possible under NFS. Is this true?
<
< We are in the process of changing over to NFS from RFS under
< 386/ix in order to use the large disks on our MV 40000 running
< DG/UX.
<
< Is seems that the only way to prevent root access on the server
< under NFS is by appointing one person as the administrator. It
< doesn't make much sense to have one person responsible for an
< entire network of 386's. He would have to be responsible for
< changing the mode of files, killing processes, etc. No one
< around here wants grunt work like this.
<
< Is this really a security issue, or are we misinformed? Is
< there a solution?
Under Ultrix NFS, you can allow the superuser (root) from a client
machine access to a particular user-id (0, for example) on the server.
I quote (without permission) from exports(8nfs):
-r=uid Map client superuser access to uid on the file sys-
tem. If you want to allow client superuser access to
the file system with the same permissions as a local
superuser, use -r=0. Use the -r=0 option only if you
trust the superuser on the client system. The
default is -r=-2 which maps superuser to nobody.
This limits the access to world readable files.
_____________________________________
Brian V. Smith (bvsmith@lbl.gov)
Lawrence Berkeley Laboratory
I don't speak for LBL, these non-opinions are all mine.markb@unix386.Convergent.COM (Mark Beyer) (12/16/89)
In article <218@inpnms.UUCP>, logan@inpnms.UUCP (Jim Logan) writes: > We all have 386's on our desks running RFS and have enjoyed > having root access to our machines, but not on the server. From > what we have read, this is not possible under NFS. Is this true? No. > Is seems that the only way to prevent root access on the server > : Maybe you and I have a different concept of what "root access on the server" is, but with NFS, root exclusion happens by default. root is mapped to uid -2 (well, in 16 bit unsigned) on the server. So files you create on the server while logged in as root on the client have "other" access, just as if you excluded root in the RFS uid rules. What did you read that made you think this wasn't so ? -- -- Mark Beyer markb@convergent.com {pyramid,pacbell,sri-unix}!ctnews!markb
dyer@spdcc.COM (Steve Dyer) (12/16/89)
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.
--
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu, dyer@hstbme.mit.edudale@lamont.ldgo.columbia.edu (dale chayes) (12/18/89)
In article <218@inpnms.UUCP>, logan@inpnms.UUCP (Jim Logan) writes: [ Several questions about NFS performance vs RFS deleted ] > doesn't make much sense to have one person responsible for an > entire network of 386's. He would have to be responsible for > changing the mode of files, killing processes, etc. No one > around here wants grunt work like this. On the issue of network maintenance: Before you decide that you want more than a small group of well organized, professional maintainers of networks mucking with a bunch of (cross)mounted file systems, consider the consequences of things like: Every local super user getting to decide what the access modes of files should be? (They will never agree!) When its the right time to update versions of public executables like operating systems, mailers, and compilers. It takes a different mind-set to maintain a network than it does to keep a single independent node running. Especially when you have users who _expect_ the network to run properly. For instance: Back in the bad(?) old days, even the most naive user who walked into the computer room and found racks open and test equipment all over the place understood that things weren't normal. Today, they just sit down at their tube, poke a key and pick up the phone when they don't get the response they expect. (Even when the news from yesterday told them the system would be down.) -- Dale Chayes Lamont-Doherty Geological Observatory of Columbia University Route 9W, Palisades, N.Y. 10964 dale@lamont.ldgo.columbia.edu voice: (914) 359-2900 extension 434 fax: (914) 359-6817
karl@ddsw1.MCS.COM (Karl Denninger) (12/20/89)
In article <725@unix386.Convergent.COM> markb@unix386.Convergent.COM (Mark Beyer) writes: >In article <218@inpnms.UUCP>, logan@inpnms.UUCP (Jim Logan) writes: >> We all have 386's on our desks running RFS and have enjoyed >> having root access to our machines, but not on the server. From >> what we have read, this is not possible under NFS. Is this true? > >No. >Maybe you and I have a different concept of what "root access on the server" is, >but with NFS, root exclusion happens by default. root is mapped to uid -2 >(well, in 16 bit unsigned) on the server. So files you create >on the server while logged in as root on the client have "other" access, just >as if you excluded root in the RFS uid rules. Yeah, but there is one problem with this: Unlike on many machines (Ultrix, Suns, etc) 386/ix doesn't permit you to turn this off or modify it. This REALLY bites. The problem we have is that we have a physically secure network. Thus, we WANT root to really be root -- on all filesystems. Allowing this lets us put one big Exabyte tape drive on the network and back up everything. It allows us many other conveniences as well. With 386/ix NFS, none of this is possible -- unless I want to write a tape server. Ugh. They claim it will be fixed soon (spring). Soon isn't fast enough. Putting a tape drive in every machine, or doing the many hours of work to do a real tape server isn't really a viable option. -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Public Access Data Line: [+1 708 566-8911], Voice: [+1 708 566-8910] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"
les@chinet.chi.il.us (Leslie Mikesell) (12/21/89)
In article <1989Dec19.195321.3431@ddsw1.MCS.COM> karl@mcs.MCS.COM (Karl Denninger) writes: >>but with NFS, root exclusion happens by default. root is mapped to uid -2 >With 386/ix NFS, none of this is possible -- unless I want to write a tape >server. Ugh. If you have rsh it should be simple enough to do tapes over the net. You might want to look at afio's special handling of host:device. Les Mikesell les@chinet.chi.il.us
dyer@spdcc.COM (Steve Dyer) (12/21/89)
In article <1989Dec19.195321.3431@ddsw1.MCS.COM> karl@mcs.MCS.COM (Karl Denninger) writes: > >The problem we have is that we have a physically secure network. Thus, we >WANT root to really be root -- on all filesystems. Allowing this lets us >put one big Exabyte tape drive on the network and back up everything. It >allows us many other conveniences as well. >With 386/ix NFS, none of this is possible -- unless I want to write a tape >server. Ugh. Can't you patch the value of the variable "nobody" in your ISC kernel? Most Sun-derived NFS ports use the value of the integer variable "nobody" as the UID to map root to. If you use "adb" or something you hack yourself to change the value of "nobody" to 0, you should be all set. I'm not an ISC user, but this is almost always consistent across most implementations. -- Steve Dyer dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer dyer@arktouros.mit.edu, dyer@hstbme.mit.edu
karl@ddsw1.MCS.COM (Karl Denninger) (12/22/89)
In article <957@ursa-major.SPDCC.COM> dyer@ursa-major.spdcc.COM (Steve Dyer) writes: >In article <1989Dec19.195321.3431@ddsw1.MCS.COM> karl@mcs.MCS.COM (Karl Denninger) writes: >> >>The problem we have is that we have a physically secure network. Thus, we >>WANT root to really be root -- on all filesystems. Allowing this lets us >>put one big Exabyte tape drive on the network and back up everything. It >>allows us many other conveniences as well. >>With 386/ix NFS, none of this is possible -- unless I want to write a tape >>server. Ugh. > >Can't you patch the value of the variable "nobody" in your ISC kernel? Yep. That was pointed out by a benevolent person; I have done it and it works -- about 95%. SUID root programs still can't get to files however. "smail3" is a prime example. It can't find the paths database if I locate it on the server. Says it can't open the file, but doesn't return an error code (yikes!). I haven't looked at this closely yet, but will have to do so..... >Most Sun-derived NFS ports use the value of the integer variable "nobody" >as the UID to map root to. If you use "adb" or something you hack >yourself to change the value of "nobody" to 0, you should be all set. Yep. >I'm not an ISC user, but this is almost always consistent across most >implementations. It is, but undocumented. No problem, that's what hacking is all about! -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Public Access Data Line: [+1 708 566-8911], Voice: [+1 708 566-8910] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"
fmcgee@cuuxb.ATT.COM (~XT6561110~Frank McGee~C23~L25~6326~) (12/23/89)
In article <957@ursa-major.SPDCC.COM> dyer@ursa-major.spdcc.COM (Steve Dyer) writes: >In article <1989Dec19.195321.3431@ddsw1.MCS.COM> karl@mcs.MCS.COM (Karl Denninger) writes: >> >>The problem we have is that we have a physically secure network. Thus, we >>WANT root to really be root -- on all filesystems. Allowing this lets us >>put one big Exabyte tape drive on the network and back up everything. It >>allows us many other conveniences as well. >>With 386/ix NFS, none of this is possible -- unless I want to write a tape >>server. Ugh. > >Can't you patch the value of the variable "nobody" in your ISC kernel? > >Most Sun-derived NFS ports use the value of the integer variable "nobody" >as the UID to map root to. If you use "adb" or something you hack >yourself to change the value of "nobody" to 0, you should be all set. > >I'm not an ISC user, but this is almost always consistent across most >implementations. I've been following this discussion, and maybe something's eluded me or there's a serious security issue here. On RFS, I can map user's out based upon which server they are on. For instance, I can say "user fmcgee on cuuxb can't access /src, but user fmcgee on otherhost can". This provides security down to the unique uid, both the login id (ascii) and uid (integer). It seems to me that NFS only provides security at the uid (integer) level. To keep people out of my files, I need to have a unique uid. Not so trivial on a network with several thousand users and several hundred hosts, of which I only control 20 or 30 hosts. Or did I miss something ? I agree and understand that "root" can be made secure or unsecure as needed. Did I miss something ? BTW, I'm not NFS bashing; there are some features of it that I like and that I feel it does better than RFS (such as portability to non-AT&T unixes). -- Frank McGee, AT&T Tier 3 Complementary Channel Sales Support attmail!fmcgee