Aucbonyx.207
net.unix-wizar
utzoo!decvax!ucbvax!ARPAVAX:Onyx:jmrubin
Fri Dec 11 07:44:22 1981
setuid and shell scripts
	The 4th Berkeley Distribution (for the Vaxen) of Unix has setuid shell
scripts.  However, this is extremely dangerous.  If a shell script uses csh
(the Berkeley shell) it source the real user's .cshrc file with the effective
uid of the owner of the setuid shell script.  Similarly, if such a shell script
is exec[e]'d with argv[0][0] == '-', it will source the real caller's .login
file.  (If the shell script uses the Bell System's shell, sh, and argv[0][0] ==
'-', it will source the real user's .profile file.

	On, for example, 2nd Berkeley Distribution Unix, an exec[e] system
call to a shell script fails.  However, many programs (including shells)
try to call a shell if exec[e] failed because it wasn't an a.out file.
(any program which uses execlp or execvp will do so.)  A typical program
looks something like this:
	execv("file",args);
/* At the point, the call failed--or else it wouldn't have gotten to here */
if (the error number is the type error number) {
put file on to the left end of args ;
execv("/bin/csh",args);
}

(You'd better be very careful on your system to make sure that if
csh is called setuid, it is called with a -f ["fast"--don't source
the .cshrc file].  In no case should csh or sh receive an argv[0]
beginning with '-'!  Also, you'd better give full path names for
all programs on such a file.)

					Joel Rubin
Date: 10 Dec 1981 1256-PST (Thursday)
From: CSVAX:ihnss!ihps3!ih1ap!dab
Subject: suid and shell scripts
Newsgroups: net.unix-wizards

The reason for the lack of suid on shell scripts is that scripts are not
"exec"ed, they are "emulated".  The only person(s) that can change a userid
is the superuser and the operating system (are slaves persons?).  In order to
allow the shell to emulate the suid bit, it (the shell) would have to run as the
superuser.  I feel this is very dangerous and would really complicate the
already messy logic in the shell.  A solution that I've used is to create a
command by the desired name (eg fred) and the script by the name concatenated 
with ".sh" (eg fred.sh) both owned by the priveledged user (the person being
suid'ed to) with the "x" and "s" bits set as required (eg 1755 u=rwxs,go=rx).
The program grabs its first arg (arg[0]) and looks for a matching .sh file.
(Note the directory searched should be fixed for security reasons
(eg `logdir owner`/sbin)).  If one is found, the permissions and owner are
checked for security reasons.  If the suid permission is missing the suid is
undone and the shell invoked on the script.  If the permissions are ok and
the owner is correct (matches the current effective id) the shell is exec'ed
thereby inheriting the real and effective ids from the command. 

The reason for all the checking is that there need be only one such command
for each user and combination of suid/guid.  All the "fred"s (see above) get
link'ed to the one command.  Nice and flexible.  So far I've not been able to
violate this one security-wise except through carelessly written scripts.

		Dave Braun

-----------------------------------------------------------------
 gopher://quux.org/ conversion by John Goerzen <jgoerzen@complete.org>
 of http://communication.ucsd.edu/A-News/


This Usenet Oldnews Archive
article may be copied and distributed freely, provided:

1. There is no money collected for the text(s) of the articles.

2. The following notice remains appended to each copy:

The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 
 Bruce Jones, Henry Spencer, David Wiseman.