johnl (02/07/83)
#N:ima:20400002:000:769
ima!johnl Feb 6 17:12:00 1983
The following question has come up lately:
A program with the "set-user-ID" bit on turns on SUID-ness (i.e.,
it runs with the effective privileges of the program owner, not
the invoker) but a program without SUID does not turn it off.
This might be a bug, or it might be a feature.
I think it's right the way it is, and gives you flexibility you wouldn't
have otherwise. Other people think it's a security hole. Do any of you
out there know of programs that depend on the behavior one way or the
other? Reply to me, I'll summarize if there's interest.
Thanks, as always, in advance.
John Levine, IECC, PO Box 349, Cambridge MA 02238; (617) 491-5451
decvax!yale-co!jrl, harpo!esquire!ima!johnl, ucbvax!cbosgd!ima!johnl
{research|alice|rabbit|amd70}!ima!johnljfw (02/09/83)
On SUID: My theory has always been that a SUID program which wishes its SUIDhood to end with the next exec should have the ability to turn off the SUIDbit conditionally on the next exec (or should have an execu which defaultly turns off the bit on exec). My immediate application for this idea was to allow users to execute programs in a directory they could not search -- they would run an intermediate program first, then it would fork and exec the intermediary program. Specifically, we have a program called "games_mgr" here which intercepts requests to play games to check whether or not it is game time, etc. I wanted the games directory to be non-searchable except to user GAMES, but this would leave the players set to that UID while playing the game (hence, in Rogue, one types !ln /usr/games/.games/Rogue_ $HOME/Ha_ha, and one can get around the whole thing). If games_mgr does the setuid(getuid()), you lose on the exec (since J.Random.User can't get there). Hence, I thought of a system call to tell the kernel to do the setuid(getuid()) upon exec (similar to FIONCLEX). No, I haven't tried it yet, since it doesn't seem (here) to have much use aside from that.
dbj.rice@Rand-Relay (03/20/83)
From: Dave Johnson <dbj.rice@Rand-Relay>
One way to solve your problem with being able to exec a program that
your real uid can't exec, but needing to undo the setuid effect of a
setuid program before doing the exec would be something like the following:
Move your games that you want to protect (in this case) from
/usr/games/ to something like /usr/games/protected/unprotected/,
and make the "protected" directory not world executable, while
the "unprotected" directory is world executable. Then, make your
games_mgr program chdir to /usr/games/protected/unprotected, then do
a setuid(getuid()) to put the effective uid back to the real uid, and
then exec the game out of the current directory. The exec will succeed
(assuming the program itself is world executable) since the kernel will
not need to look outside the current directory to find the program.
The only bad side-effect of this is that the program will be running
with a current directory other than what the user had in his shell
when he invoked it. This could cause confusion in naming files for
saving games, etc., but is better than modifying the kernel...
Dave Johnsonfred.umcp-cs@Udel-Relay (03/23/83)
From: Fred Blonder <fred.umcp-cs@Udel-Relay> From: decvax!genradbo!mitccc!jfw@UCB-C70 (John Woods) Specifically, we have a program called "games_mgr" here which intercepts requests to play games to check whether or not it is game time, etc. I wanted the games directory to be non-searchable except to user GAMES, but this would leave the players set to that UID while playing the game. If games_mgr does the setuid(getuid()), you lose on the exec. Hence, I thought of a system call to tell the kernel to do the setuid(getuid()) upon exec. How about just setting up a ``games'' group? The directory and all the games within it would be owned by group ``games'' and set to mode drwxr-x---. ``Games_mgr'' could be set-gid so that it could access the games. Even if a user got his own link to a game he wouldn't be able to execute it since he would have no way (other than games_mgr) to set his group id to ``games''.