Unix security additions

[Tom Christiansen]

>From the keyboard of craig at bacchus.esa.oz.au (Craig Macbride):
:>o  Eliminating setuid shell scripts
:
:A good idea in theory, but the security of the system is still largely a
:matter of how it's administered. Why shouldn't people who want to use setuid
:shell scripts be allowed to? Because IBM or AT&T says so? 

Do you think they say for just for the sake of pervicacity?  There are
two very good reasons for not running suid scripts.

The first is that there is a well-known and almost never-fixed race
condition in the kernel by which the mere presence of a setuid root
script on your system will allow anyone to become root who can make a
link to that file.  This has been known for many years, but almost no
vendor fixes it.  At most, if you're very lucky, they disable it.  You
should complain bitterly to your vendor if they've done neither, as
they are being negligent.  Most are.

You might like to know that Maarten Litmaath's indir program can be
used to circumvent this bug.

The second reason for never using setuid shell scripts is that the
amount of effort you have to go through to guarantee their security
even once the aforementioned bug is fixed is truly exhaustive.  Merely
wrapping the shell script with a setuid C wrapper does nothing to deal
with all these problems.  I have appended a posting detailing these.

Two more quick points before that, though.  First, the perl language had
as one of its design goals the ability to write secure programs in it.  A
suid program written in perl is often safer than a C program, because the
run-time system catches brain-dead errors that neither shell scripts nor C
programs check for.  Check out the section on "Setuid Scripts" in the perl
man page or the perl book for details.

The other thing is that often I have a brief program that I believe
gives you the ability to grant someone edit rights on a file from a
suid program without giving away the whole farm.  It does this by
putting the file in a chrooted directory while it's being edited.  I'll
be happy to mail this out to anyone who asks, or to post it if there's
sufficient interest.

--tom



------- Forwarded Message

Date:         10 Aug 90 19:41:32 GMT From:         vlb at magic.apple.com
(Vicki Brown) Subject:      Re: Suid script security Organization:
Apple Computer Newsgroups:   comp.unix.questions


In article <14920003 at hpdmd48.boi.hp.com> markw at hpdmd48.boi.hp.com (Mark
Wolfe) writes:  > >    I know that suid scripts are a bad idea from
reading comp.questions and >comp.wizards over the last year or so. It
seems that just about every guru >in the world has posted a warning NOT
to do it, so I decided I would follow >the advice (it's a rare subject
that all guru's agree on). However, it appears >that I'm now about to
have one of these ugly animals forced on me from above, >so I'd like
some advice:  > > 1)  Just what are the security risks involved? (i.e.
how would someone attack >     a system via one of these).  > > 2)
What can I do to make this as secure as possible?

Warning - very long response ahead.  Proceed at your own risk.  There
was a very interesting paper in the USENIX Association's publication,
 ;login: ( "How To Write a Setuid Program", Matt Bishop, ;login:  Vol
12, Number 1, January/February 1987).  An excerpt:

    Some versions of UNIX allow command scripts, such as shell scripts,
    to be made setuid ... Unfortunately, given the power and complexity
    of many command interpreters, it is often possible to force them to
    perform actions which were not intended, and which allow the user
    to violate system security.  This leaves the owner of the setuid
    script open to a devastating attack.  In general, such scripts
    should be avoided.

    ... suppose a site has a setuid script of sh commands.  An attacker
    simply executes the script in such a way that the shell ... appears
    to have been invoked by a person logging in.  UNIX applies the
    setuid bit on the script to the shell, and ... it becomes
    interactive...

    One way to avoid having a setuid script is to turn off the setuid
    bit on the script, and ... use a setuid [binary] program to invoke
    it.  This program should take care to call the command interpreter
    by its full path name, and reset environment information such as
    file descriptors and environment variables to a known state.
    However, this method should be used only as a last resort and as a
    temporary measure, since with many command interpreters it is
    possible even under these conditions to force them to take
    undesirable action.

The biggest problem with shell scripts is that you (the programmer /
administrator) have very little control over the programs which run
within the script.  As a very real example, I ran across a script which
allowed users to enter bug reports, using the "vi" editor.  The script
was setuid root, because it wanted to save files in funny places.  The
programmer had guarded against shell escapes (a known feature of vi),
by making this script the login shell.  However, he couldn't guard
against another feature
	:e /etc/passwd

You can attempt to make your script as safe as possible by
	1) being very restrictive in your choice of UID.  That is,
	   make the script setuid for a non-privileged user, rather
	   than root (for example, if it must write a log file, could
	   the log file live in some locked area, accessed only by a
	   new and otherwise non-privileged account?) 2) making the
	script setgid rather than setuid, with a very
	   restricted GID (see #1) 3) ensuring that the script is
	short, very simple, and does not
	   make use of commands such as `vi', `mail' or anything
	   interactive.  setuid programs should do ONE thing only, and
	   in a non-complex manner.  4) setting the PATH, IFS, and
	other environment variables explicitly
	   within the script 5) locking down the permissions on the
	script.  If possible allow it
	   to be run only by group members.  Never allow write
	   permission.  6) If your version of UNIX permits, take away
	read permission for
	   anyone other than the owner.  It's a bit harder to break
	   something if you can't see how it works.  7) Rewrite it in C
	(carefully) 8) Convince your management that they don't really
	need this.

If you plan to keep the script, or re-write it, try and get a copy of
the paper.  If you can't find it, send me mail.
   Vicki Brown   A/UX Development Group         Apple Computer, Inc.
   Internet: vlb at apple.com                      MS 58A, 10440 Bubb Rd.
   UUCP: {sun,amdahl,decwrl}!apple!vlb          Cupertino, CA  95014
   USA
	      Ooit'n Normaal Mens Ontmoet?  En..., Beviel't?  (Did you
	  ever meet a normal person?  Did you enjoy it?)

------- End of Forwarded Message