Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!samsung!uunet!ssbell!mcmi!dsndata!wayne
From: wayne@dsndata.uucp (Wayne Schlitt)
Newsgroups: comp.sys.hp
Subject: Re: How can I give users root-like privs. w/o the passwd ?
Message-ID: <WAYNE.89Dec24102820@dsndata.uucp>
Date: 24 Dec 89 16:28:21 GMT
References: <2643@umbc3.UMBC.EDU> <3140011@hpldsla.HP.COM>
Sender: wayne@dsndata.UUCP
Organization: Design Data
Lines: 72
In-reply-to: djw@hpldsla.HP.COM's message of 21 Dec 89 19:46:44 GMT


In article <3140011@hpldsla.HP.COM> djw@hpldsla.HP.COM writes:
> 
> Here is a quick example that uses a shell script.
> 
> #!/bin/sh
> #
> #	sysstop.sh - shutdown the system.
> #
> PATH=/bin; export PATH	# VERY important.

it is also _very_ important to set the IFS variable to space, tab and
newline via:

IFS=" \t\n"; export IFS

for those who havent used the IFS variable much ( :-> ), it is the
"internal field separator", and it is what the shell uses to separate
words.  as an example, if the IFS was set to "r", then the following
command would have been parsed as the command "if g" and the option
"ep $LOGNAME /usr/adm ...".  there are a lot of times that the bad
guys can use this to break security.


> if grep "$LOGNAME" /usr/adm/shutdown.list > /dev/null 2>&1

using $LOGNAME for anything important is a very bad thing to do.
anyone can set it to be anything they want.  it is my understanding
that using the command whoami isnt much better because it can be
tricked into using the $LOGNAME variable to tell you who you are.

> then
> 	cd /
> 	exec /etc/shutdown
> else
> 	echo "permission denied" >&2
> 	exit 2
> fi
> 


although i am not aware of all of the holes, from what i know, setuid
shell scripts are usually a major no-no.  the major problem with
setuid shell scripts are:

1) any one who can execute them can read them.  this gives the bad
   guys lots of information on how to break them.  if you use a
   compiled C program, you can take off the read permission and the
   bad guys have a lot less to go on.

2) if you are writing in C, you can change your effective userid back
   to something "safe" after you have opened the files you need.  you
   cant set your userid in a shell script

3) /bin/sh (the program that runs your shell scripts) is a fairly
   large and complicated program.  this leaves lots of subtle things
   that the bad guys can use to break your scripts.  as an example, i
   believe on some systems, if you invoke the shell script via a C
   program with the "exec" command and add a minus sign to the
   beginning of the shell script name, it will always execute the
   users .profile.  and since the bad guys can usually write to their
   .profiles, they can do anything they want...

unix isnt very good about being able to give away just some of roots
privileges.  in many ways it is better to just give in and trust a few
people with the root password.  they will tend to be more careful with
it's power and they will feel like they are responsible for what
happens.  of course, this has left the realm of computer security and
gone to into the realm of human nature and everyone is different, but
in either case, you are going to have to watch the system carefully.

-wayne