mcgrew@topaz.rutgers.edu (Charles) (12/25/88)
Hi, Concerning setuid-ing fingerd to make it not run as root, can anyone think of a reason of not setuid-ing finger to 'who'? That seems to be a fairly inoffensive uid... Charles [[ Well, I don't think "who" is assigned in the distributed system, but the idea of inventing your own username and allocating a uid to it is a very good one. --wnl ]]
dik@uva.UUCP (Casper H.S. Dik) (01/05/89)
mcgrew@topaz.rutgers.edu (Charles) writes: >Concerning setuid-ing fingerd to make it not run as root, can anyone think >of a reason of not setuid-ing finger to 'who'? That seems to be a fairly >inoffensive uid... > >Charles Making fingerd setuid to some 'innocent' user won't help. The man page for execve states: If a program is setuid to a non-super-user, but is executed when the real uid is 'root', then the program has the powers of a super-user as well. If you want fingerd to run as a unpriviliged process add a line setuid(some-uid); to the source. Casper Dik. Casper H.S. Dik University of Amsterdam | dik@uva.uucp The Netherlands | ...!uunet!mcvax!uva!dik [[ C'mon people, this really is a non-problem. The official "worm-killer" patch distributed by Sun (and available in the Sun-Spots archives) has the entire source to fingerd in it. The entire, recompilable, C source code. So go stick a line in the source that does a setuid(X) for some value X. --wnl ]]
trn@aplcomm.jhuapl.edu (Tony Nardo) (01/05/89)
In article <CMM.0.88.598291721.mcgrew@topaz.rutgers.edu> you write: >Concerning setuid-ing fingerd to make it not run as root, can anyone think >of a reason of not setuid-ing finger to 'who'? That seems to be a fairly >inoffensive uid... >[[ Well, I don't think "who" is assigned in the distributed system, but >the idea of inventing your own username and allocating a uid to it is a >very good one. --wnl ]] That turns out not to be the case. Any system which is allowed to mount your disk(s) may also overwrite the contents of any file *NOT* owned by root. Thus, my "finger fix" (chown nobody /etc/in/fingerd [well, I used "news" originally...) leaves the system vulnerable to overwrites by superusers on "trusted" systems in /etc/exports. [[ So leave the file owed by root and put a "setuid" call in the source. See previous message. --wnl ]] If you export files widely (and remember, a partition name with *no* host name entry next to it means that said partition is *universally* exported!), changing the ownership of "in.fingerd" to a non-root name may be worse than simply living with the original bug. [[ Don't export files widely. Export to trusted hosts. If you can't trust your Ethernet neighbors, who can you trust? --wnl ]] If I could get my hands on source code for finger.c, I'd be HAPPY to patch this problem *properly* -- or at least make the attempt. Unfortunately, getting source code for a single utility is easier said than done. [[ A fix to fingerd (the source for which *is* widely available) is, I believe, all that is needed. Make both finger and fingerd owned by root but *NOT* setuid. Add "setuid(1)" (or whatever) to fingerd, which will fail if not invoked as root (which is still just fine). I see no problem with that setup. --wnl ]] (My current idea of a proper fix: if a valid user name is specified, have finger.c setuid to that user's UID *before* attempting to open .plan or .project files. This will prevent user "x" from illegally accessing files owned by user "y" via shady file linkages. It also allows user "x" to protect his home directory but still have a universally accessible .plan file, if so desired.) [[ "cd; chmod 711 .; chmod go-rwx * .[a-z]*; chmod 644 .plan". Move anything you really want protected into a subdirectory. But as you have already pointed out, this won't be any protection against root on a machine that can mount your disk. --wnl ]] Until 1/4, I will be unreachable directly on the Internet. Your best bet is to either use UUCP or, if you can reach mimsy via the Internet, try sending mail to me at "aplcomm!trn@mimsy.umd.edu". [[ I'm really getting tired of this discussion. Can we call it quits now, please? --wnl ]] ARPA: trn@aplcomm.jhuapl.edu UUCP: {backbone!}mimsy!aplcomm!trn BITNET: trn@warper.jhuapl.edu
guy@uunet.uu.net (Guy Harris) (01/13/89)
>Making fingerd setuid to some 'innocent' user won't help. > >The man page for execve states: If a program is setuid to a non-super-user, >but is executed when the real uid is 'root', then the program has the >powers of a super-user as well. The caveat is somewhat confusing. I presume what it's trying to say is that the program has *some* of the powers of a super-user and can, if it chooses, obtain more of them. A few places in the kernel check either for effective *or* real UID being 0 (I don't remember which ones, offhand), and if the real UID is 0 the program can set its effective UID to match its real UID and thus get super-user privileges. Either that, or it's describing a state of affairs that was true in older versions of UNIX, but that is neither true in 4.xBSD nor System V, and thus not true in many (most?) of the UNIXes around today. Back in V7, if the super-user ran a set-UID program, the process running the program was not made set-UID; this is not the case in more modern UNIXes - the process is made set-UID just as if a user other than the super-user ran it. In any case, if you have a program that is set-UID to some user ID that does not have permission to read some file X, and the super-user runs that program, the program will not be able to open file X for reading unless it sets its effective UID to match its real UID (i.e., root). I tried this on a 4.0 system with a set-UID "cat" (which doesn't set its effective UID to match its real UID), and it is indeed true. [[ This was sent in later: --wnl ]] More precisely, the man page states (in the SunOS 4.0 and 4.3-tahoe manual) that the program has *some* of the powers of a super-user. This is, as I mentioned, true, but the powers in question do not include the power to read arbitrary files.