Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!munnari.oz.au!sirius.ucs.adelaide.edu.au!adelphi.ua.oz.au!mferrare
From: mferrare@adelphi.ua.oz.au (Mark Ferraretto)
Newsgroups: comp.unix.questions
Subject: How secure are shell scripts? (summary)
Message-ID: <1576@sirius.ucs.adelaide.edu.au>
Date: 10 Oct 90 03:37:21 GMT
Sender: news@ucs.adelaide.edu.au
Reply-To: mferrare@adelphi.ua.oz.au (Mark Ferraretto)
Organization: Department of Physics, University of Adelaide, South Australia
Lines: 134
Nntp-Posting-Host: adelphi.ua.oz.au

My original question:

> I want to write a program that all of our users will be accessing and the 
> program may be suid to root so that certain users may write to a
> writeprotected
> directory.  At the moment the program is a shell script and I want to know if
> this is less secure than writing C code.  Either way the program would have
> the protection as 755 though there is no need for the users to read it. 

> Please mail responses to me and I'll summarise if there is enough interest.

Everybody said that a C program is definitely more secure than a shell script
especially when the program is setuid to root.  People suggested setuid to
some group or special user instead of root so that users can still write to
that directory.

darrenr@mullauna.cs.mu.oz.au :

A better way yet, is to give ownership to some user/group so that those users
can write to it.
Or better again, create a new user & group for which this new directory belongs
to and make the program suid to that user/group.

Use root access as your LAST alternative - and then do it VERY carefully.
ie, check every fork()/exec() call it makes to be sure there isn't a way for
the user to get a shell escape - they are EVERYWHERE too.

...rember this : make as little of the
system as possible dependant on root access. (ie have user/group bin own /bin,
/usr/bin, etc...)


Unless you are EXTREMELY careful, yes!
Someone can set a path with, say, their home directory as first thing in path.
They then copy 'sh' into their home directory and call it 'fred', where 'fred'
is some command in the script. Next step, run script and get given an
interactive, fully functioning shell as _root_!!!! Yuk.

Ways around this:
- Be _very_ careful to set PATH explicitly in the script, such that it doesn't
include any directories (especially '.'!) which can _ever_ be writeable to
normal users. 
- Use absolute path names for _every_ single command in the file.
- Write it in C.

I think the last of these is greatly preferable, as there's no way (unless you
write some really silly code) that users can get other programs to run as root.

Another comment: why does it have to be root? If security worries you at all,
make the directory owned by someone else, but not root. Even better, just give
it a special _group_ of its own, and make the program setgid. Then if someone
breaks your program, all they can do is access that directory, not fuck your
whole system up.


Adam Bryant:

I tend to think that C source is much more secure, since any actual
spawning of jobs is totally controlled by the programmer, while this
might not be the case in an insecure shell script.


raymond@math.berkeley.edu:

Suppose your script is in /bin/sh, and is called /usr/local/bin/foo

I type

	ln -s /usr/local/bin/foo -x
	-x

If your #! line is naively set to

	#!/bin/sh

this gives me superuser privileges, since the command line that gets
executed is

	/bin/sh -x


wsinpp@info.win.tue.nl:

At any time prefer C code !. It takes only two commands to become
the user who owns the suid script ! If you have a suid shell script
owned by root. I can become root in just two commands !

King M. Lee <klee@orville.nas.nasa.gov>

Setuid to root is very dangerous.  It may be better to
let a non-root user, say admin, own the directory and 
setuid to admin.

Pat Barron <pat@orac.pgh.pa.us>

Having a setuid shell script is just asking for trouble.  There are a large
number of ways for a random user to subvert a setuid shell script; playing
games with $PATH, fooling with $IFS (in /bin/sh), diddling shell options,
and/or exec'ing the setuid script as "-csh" or "-sh" (thus fooling the shell
into thinking it's interactive, and forcing the execution of any commands
in the user's .login or .profile) are some ways that spring immediately to
mind.  There are countless others.

Write your setuid program in C.  It isn't a perfect solution, but you've
got a much better chance of making it secure than you do if you use a
shell script.

dce@krusty.smsc.Sony.COM

setuid(root) shell scripts are considered dangerous.  Even assuming
that you can write a shell script that isn't potentially broken (for
example, using $* when you mean "$@" or ${1+"$@"}, or things like
test "$x" = "whatIwant"), there are ways for people to get past
security.

While it isn't any less bulletproof to make the shell script setgid and
use group permission, you can make the group generally powerless and
thus stop someone using the script to gain special privilege from
doing much with it.

Supposedly, running the shell script with no special permissions
from a C program that is setuid/setgid is more secure, though I
don't remember why.

If you really are worried, write the C program and save yourself
the anxiety.

Which is exactly what I'll be doing!!

Thanks to everyone for responding
       _             Name  : Mark Ferraretto
      \  \           Place : Department of Physics and Mathematical Physics
 ||     \  \                 University of Adelaide
==========>==>==--   Aarnet: mferrare@physics.adelaide.edu.au