[olug] chmod u+s

[Christopher Cashell]

At Thu, 03 Jun 04, Unidentified Flying Banana Jay Hannah, said:
> On Jun 3, 2004, at 6:29 PM, Phil Brutsche wrote:
> >The question you need to ask yourself is "does the suid bit work on 
> >shell scripts?".  It doesn't here (Debian "testing" aka sarge, kernel 
> >2.6.7-rc2-bk1)

Just a minor addition to this comment, SUID/SGID shell scripts won't
work with most recent Linux distributions.  This is both a bash, and a
kernel (2.0.x+ as I recall), issue.

> Hmm... Perhaps I hit the "write a C wrapper!" phenomenon again? This 
> seems to come up for me every 3 years or so. It continues to strike me 
> as remarkably silly for shell scripts to not work and little 3-line C 
> wrappers to work. I've never understood why C wrappers would ever be 
> considered more secure.

First I'll explain 'why' this doesn't work.  To start with, bash won't
let you (by default) run privileged scripts.  You have to use the '-p'
switch to allow it:

 -p   Turn on privileged mode.  In this  mode,  the  $ENV  and $BASH_ENV
      files  are not processed, shell functions are not inherited from
      the environment, and the SHELLOPTS variable, if it appears in
      the environment, is ignored.  If the shell is started with the
      effective user (group) id not equal to the real user (group) id,
      and the -p option is not supplied, these actions are taken and
      the effective user id is set to the real user id.  If the -p
      option is supplied at startup, the effective user id  is not
      reset.  Turning this option off causes the effective user and
      group ids to be set to the real user and group ids.

However, recent versions of the Linux kernel go even farther in
preventing SUID/SGID shell scripts (among other scripts).  

My understanding of things is that the kernel ignores whether an
interpreted program has the setuid bit set -- it essentially just
executes the interpreter given after the #!, passing the full pathname
of the file containing an interpreted program as the first argument.
Because of this, the Linux kernel (starting with 2.0.x, I believe, along
with many other modern Unices (but not all)) won't allow you to write
SUID/SGID shell scripts.

There is, though, a way or two around it.  If the interpreter wants to
then go ahead and look at the setuid or setgid bits on the file it was
given as the first argument (the way perl and suidperl do) then that's
the interpreter's business.  This generally requires that the
interpreter be SUID/SGID and be smart enough to handle this securely.

Alternately, you could just make bash SUID, but I wouldn't recommend
that (for obvious reasons. ;-)

There is a very good justification for why things are done this way.
Particularly in the case of shell scripts, they are inherently unsafe,
and it is almost *impossible* to write a secure shell script.  Because
users can change their path, define aliases, and do all kinds of
interesting things with variables, any shell script that accepts any
untrusted input can almost certainly be exploited. (At its simplest,
imagine if a SUID shell script did 'ls' somewhere, and was run by a user
who had changed the PATH and added a different 'ls' command that
actually did 'rm -rf /'.)

> j
> Omaha Rumor Mongers

-- 
| Christopher
+------------------------------------------------+
| Here I stand.  I can do no other.              |
+------------------------------------------------+