david@ukma.UUCP (10/31/87)
We were brainstorming the other day and it seems likely that within
the next couple of years we could have lots of workstations on campus
(my guess is 500 within 2 years) that are diskless. Then, we're
getting an IBM 3090 for the Computing Center, run UTX on it and
use disk space over there to support a lot of these workstations.
Then we realized we'd have to coordinate our user id's with them.
Then we realized there's only 16-bits of user id's available and we
could easily run out ...
Even if we don't use the above scenario of turning the 3090 into
a fileserver ... it seems likely that we will eventually have
a similar sort of situation with everybody on campus sharing
a global NFS file system (er.. at least, *most* everybody) and
we'd have to coordinate user-id's etc etc etc. And the possibility
of running out of user-id's still remains.
(As does security problems like -- if you're root on one nfs machine
you can instantly become root on any other nfs machine -- professors
who're accustomed to students NOT being on these machines, so they
write their exams here ...)
--
<---- David Herron, Local E-Mail Hack, david@ms.uky.edu, david@ms.uky.csnet
<---- {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET
<---- "The market doesn't drop hundreds of points on a normal day..." --
<---- Fidelity Investments Corporationdavid@ms.uky.edu (David Herron -- Resident E-mail Hack) (11/03/87)
A lot of people have become confused over the following paragraph ... it's a shame too, 'cause it was simply a side comment and not the main point of the posting. In article <7605@g.ms.uky.edu>, I wrote: > (As does security problems like -- if you're root on one nfs machine > you can instantly become root on any other nfs machine -- professors > who're accustomed to students NOT being on these machines, so they > write their exams here ...) Many people have told me that root -> uid -2 across NFS. I already am very very familiar with this (thank you), and that is NOT what I had meant. Rather ... Consider the following situation. You're root on a machine that serves part of it's filesystem. You put a /bin/sh somewhere and make it setuid to root etc. Then you go over to another machine and execute that /bin/sh. Voila you're root over there. Here this can happen because one of our professors requires root access to his workstation and part of his workstations filesystem is globally mounted. Fortunately he's a good guy and recently became part of the support group so it doesn't matter. I've since read through the NFS Protocol Description which came along with our Mt Xinu manuals ... Everybody please read section 2.2.2. where it talks about what I said in the previous paragraph. But within the time frame of our brainstorming session (2 years) we could easily have our instructional lab full of machines running something which'll be doing NFS. But we hadn't thought through the consequences of AT&T and Sun merging the many-varied threads of Unix into one. Part of this means a merging of NFS and RFS. (Will they meet halfway and call it PFS???) :-) Since RFS has some of the proper security features, and the NFS people know the problems already, then this will probably be fixed around SysVr10. The main thrust of my article had been to cause thought on what a large distributed system would mean. Right now our system is fairly limited. We've got 5 vaxen and a sun serving about 20 vax workstations and 5 sun workstations. But in a couple of years there could be many many departments owning systems capable of operating with NFS (PFS?). Especially with diskless workstations being so cheap nowadays ... they'd just have to find some machine to serve them disk blocks... The nearer to the client machines the better. Anyway, what would this system be like? A common file system serving large parts of this University? It's sort of mind boggling. I don't know if we'd do something so mundane as running out of user-id's. 64000 is a large number still. But there are somewhat more people than that on campus, and if we ever got to a situation where *everybody* had accounts ... and they all had to be in one filesystem and the filesystem were as it is now ... -- <---- David Herron, Local E-Mail Hack, david@ms.uky.edu, david@ms.uky.csnet <---- {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET <---- "The market doesn't drop hundreds of points on a normal day..." -- <---- Fidelity Investments Corporation
guy%gorodish@Sun.COM (Guy Harris) (11/03/87)
DISCLAIMER: none of this in any way reflects Sun Microsystems policy. If you want to know something about what the merged OS will end up as, or whether any of the stuff described in the paper described below will end up in a SunOS release, ask your sales office, or some official Sun Microsystems spokescritter, for the official story. (I write code, I don't make policy. On the whole, I'm just as glad I don't.) > Consider the following situation. You're root on a machine that serves > part of it's filesystem. You put a /bin/sh somewhere and make it setuid > to root etc. Then you go over to another machine and execute that /bin/sh. > Voila you're root over there. Not if the machine that's mounted that file system has mounted it "no-set-UID." The ability to say "don't believe set-UID bits when running programs from this file system" has been in SunOS since at least release 3.2. I don't know what other UNIX systems supporting NFS client code implement this, although I presume at least some of them have picked it up. > But we hadn't thought through the consequences of AT&T and Sun merging the > many-varied threads of Unix into one. Part of this means a merging of NFS > and RFS. (Will they meet halfway and call it PFS???) :-) Merging System V and 4BSD makes sense; the two systems are (opinions to the contrary nonwithstanding) recognizably descended from Research UNIX, and the true differences (as opposed to the "system A has this feature and system B doesn't" differences - those can largely be handled by adding the feature in question to system B) can generally be handled by providing multiple environments (not necessarily complete universes; it doesn't make sense to provide e.g. two versions of "egrep" or "stat" when you can provide one that's compatible with both, which you can do). "Merging NFS and RFS" is a different story. The two did not start from the same design or the same code; it's not a question of making small changes or providing small mode switches to make something that can look like either. It strikes me as similar to merging C and Pascal (as opposed to e.g. merging vendor X's and vendor Y's extensions to Pascal). You can certainly make a system that supports both as independent mechanisms; it could support other remote data access mechanisms as well. > Since RFS has some of the proper security features, and the NFS people > know the problems already, then this will probably be fixed around SysVr10. There are other ways of dealing with this problem than by doing straight UID to UID mapping. See "Secure Networking in the Sun Environment", by Brad Taylor and Dave Goldberg, in the 1986 summer USENIX proceedings. (Also note that straight UID to UID mapping doesn't work if both systems don't support UNIX-style UIDs.) Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
roy@phri.UUCP (Roy Smith) (11/03/87)
In article <7623@e.ms.uky.edu> david@ms.uky.edu (David Herron) talks about
the problems of running out of user id's on very large (campus-wide, or
even bigger) inter-NFS-ified machines.
Seems to me heirarchial domains work for everything else; why not
for user id's? Why do we need a numeric user id at all; how terrible would
it be if your id (as stored in the file system) is simply your domain
qualified user name, "david.ms.uky.edu". What's 16 bytes in the inode, or
even 64, matter?
--
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016greg@muddy.cs.unlv.edu (Greg Wohletz) (11/04/87)
In article <7605@g.ms.uky.edu> david@ms.uky.edu (David Herron -- Resident E-mail Hack) writes: >(As does security problems like -- if you're root on one nfs machine >you can instantly become root on any other nfs machine > I do not belive that the above is correct, or at least you can set things up to make it incorrect. Here if a user is root on one machine, he accesses remote files as if he were uid ``-2''. This is the default under sunOS 3.4 (and probably earlier). --Greg
lvc@tut.UUCP (11/04/87)
In article <32716@sun.uucp>, guy%gorodish@Sun.COM (Guy Harris) writes: ... >Not if the machine that's mounted that file system has mounted it >"no-set-UID." The ability to say "don't believe set-UID bits when >running programs from this file system" has been in SunOS since at >least release 3.2. ... Hopefully this feature includes no-set-GID and fail opens for special files. One old (internal only) AT&T version of UNIX did these all. It was called the restricted file system, handy for foreign disks and tapes. I'm still waiting for AT&T to put it in System 5. Larry Cipriani tut!lvc
trt@rti.UUCP (Thomas Truscott) (11/05/87)
In article <694@jimi.cs.unlv.edu>, greg@muddy.cs.unlv.edu (Greg Wohletz) writes: > In article <7605@g.ms.uky.edu> david@ms.uky.edu (David Herron -- Resident E-mail Hack) writes: > >(As does security problems like -- if you're root on one nfs machine > >you can instantly become root on any other nfs machine > > > > I do not belive that the above is correct ... > [because root can be mapped to -2 elsewhere]. [We are talking vanilla nfs here, your mileage may vary.] If you are superuser on one nfs machine and want to subvert another but your uid 0 is mapped to -2 elsewhere and no other system honors the set-user-id bits on your programs, then straightforward attacks are out. But consider that *every other* uid is mapped flat. So you have the powers of *every other* uid on every other file system you can reach. Only the insatiable power-hungry could want more, and for them a simple trojan horse attack should finish the job. Tom Truscott
chris@mimsy.UUCP (Chris Torek) (11/06/87)
In article <7623@e.ms.uky.edu> david@ms.uky.edu (David Herron -- Resident E-mail Hack) writes: >Many people have told me that root -> uid -2 across NFS. ... that is >NOT what I had meant. ... You're root on a machine that serves part >of it's filesystem. You put a /bin/sh somewhere and make it setuid >to root etc. Then you go over to another machine and execute that >/bin/sh. Voila you're root over there. It is worse than this: Even if you do not act as a server for any other hosts, as root you have complete access to all non-root files on every other machine on your NFS network---simply because as root you can become any non-root person and then access NFS files as that other person. (Sun is working on a real authentication system.) >I don't know if we'd do something so mundane as running out of user-id's. >64000 is a large number still. 4BSD is headed towards 32 bit uid and gid values. That was part of the purpose behind adding `typedef u_short uid_t' to <sys/types.h>. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
mjr@osiris.UUCP (Marcus J. Ranum) (11/10/87)
Yah, there's always the problem of "root" on machine A who does an "su bin" "rlogin foob" --mjr(); -- "We're fantastically incredibly sorry for all these extremely unreasonable things we did. I can only plead that my simple, barely-sentient friend and myself are underpriviledged, deprived and also college students." - Waldo "D.R." Dobbs.
dyer@spdcc.COM (Steve Dyer) (11/11/87)
At MIT Project Athena, where every public workstation either has a well-known
root password or can be rebooted at will to gain a root shell, we implemented
a VERY simple hack to increase the security of NFS filesystems in this
environment. All user ids, not just uid 0, are mapped to "nobody" on a
NFS server in the absence of a unique uid-mapping structure which associates
an [IP address, remote uid] pair with set of credentials for that particular
server. Each NFS server maintains its own database of credentials, so that
a server may be open for everyone in the community to use, or restricted to
just a few. A uid map entry is created on a NFS server through a client program
which issues a new mountd RPC call to the server to install a uid map entry.
Secure authentication of the RPC request to mountd (which is the key to its
usefulness) is performed by rpc.mountd on the server using the Kerberos
authentication system, also developed at Project Athena.
The total amount of kernel code was incredibly small; no more than a few pages,
and most of that was just the bookkeeping of hashing/creating/deleting uid
map entries--the code added to the NFS server itself consists of only one line!
The changes to rpc.mountd and the new client program are similarly straight-
forward. There is virtually no performance penalty in choosing this, since
each NFS request is not individually authenticated; only the installation of
credentials for a uid on a host. Jeff Schiller and Bill Sommerfeld of Athena
worked on the design and implementation of the uid map system and its kernel
changes, while I designed and implemented the client program to install the
map and added code to rpc.mountd. No more than a month's worth of work on
a part-time basis.
I believe there will be a session at the upcoming USENIX in Dallas where
Athena staff will be discussing Kerberos and the NFS changes (which are only
one application of Kerberos.)
--
Steve Dyer
dyer@harvard.harvard.edu
dyer@spdcc.COM aka {ihnp4,harvard,linus,ima,bbn,m2c}!spdcc!dyer