Path: utzoo!utgpu!watmath!clyde!att!rutgers!cmcl2!yale!husc6!ogccse!blake!uw-beaver!rice!sun-spots-request
From: trn@aplcomm.jhuapl.edu (Tony Nardo)
Newsgroups: comp.sys.sun
Subject: Re: making fingerd non-root
Message-ID: <8812260441.AA04443@warper.jhuapl.edu>
Date: 5 Jan 89 05:33:45 GMT
Sender: usenet@rice.edu
Organization: Faculteit Wiskunde & Informatica, Universiteit van Amsterdam
Lines: 54
Approved: Sun-Spots@rice.edu
Original-Date: Sun, 25 Dec 88 23:41:13 EST
X-Sun-Spots-Digest: Volume 7, Issue 89, message 4 of 11
X-Issue-Reference: v7n75

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