Path: utzoo!utgpu!attcan!uunet!husc6!mailrus!ncar!gatech!ulysses!cjc
From: cjc@ulysses.homer.nj.att.com (Chris Calabrese[rs])
Newsgroups: comp.unix.wizards
Subject: Re: Reasons for restricting su privilege?
Summary: I did something like this in school
Message-ID: <10749@ulysses.homer.nj.att.com>
Date: 21 Oct 88 12:34:27 GMT
References: <6606@pyr.gatech.EDU> <25003@tut.cis.ohio-state.edu> <3185@tekcrl.CRL.TEK.COM>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 38

In article <3185@tekcrl.CRL.TEK.COM>, eirik@tekcrl.TEK.COM (Eirik Fuller) writes:
> In article <25003@tut.cis.ohio-state.edu> karl@dinosaur.cis.ohio-state.edu (Karl Kleinpaste) writes:
> ) Personally, I advocate a menu-driven setuid-root program which allows
> ) ...
> 
> Yeah, sure, but what if this spiffy menu contraption allows its luser
> to make new accounts?  "Gee, maybe I'll make an account with uid 0,
> and put /bin/csh as its shell, and leave the password off until
> someone comes along and puts one in, and see what happens ..."
> ...

I did one of these menu things when I was in school.  The way
I solved these types of problems was:
	You could add, modify, and delete lines in /etc/passwd,
	but only using the supplied menu based editor, and
	only for users with uid and gid >= 100.

	You could su to any account with uid and gid >= 100.

	You could view any file.

	You could remove and file in /etc (and mabee /bin but
	I don't remember that part to well).

	File viewing and removing operations were done with
	internal code so there were no leaks from possible
	security holes in more, pg, cat, rm, etc.

All in all it worked pretty well (though the code is pretty
hackish compared to what I can do now :-).

If anyone wants source I can get it, though I'll have to
retrieve it from tape.
-- 
--------
	Christopher J. Calabrese
	AT&T Bell Laboratories
	ulysses!cjc