Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'Potential warning: 10.3.9 disables SUID/SGID flag' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Potential warning: 10.3.9 disables SUID/SGID flag
Authored by: gshenaut on Apr 18, '05 02:36:46PM
My opinion: this is really, really stupid. What's next, refusal to accept wildcards in rm(1) commands?

Here's the situation as I see it: you can still use chmod to set the suid bit on any file, including scripts. If you execute #! script, its suid bit is ignored. If you execute a shell script without a #!, then bash & csh ignore the suid bit, but ksh hangs or gives a bus error.

You can still easily write & compile a one-line shim along the lines of

main(){execl("/Users/mylogin/libexec/myscript", "msyscript", 0);}
and setuid on its binary to run "myscript", which can still be a #! script.

Since this is a (minor) hassle, it will lead to the temptation to write a more general script that will allow any program to be run suid; if anyone succumbs to that temptation (and I bet some will do so), the result will be a much worse security problem.

What is gained by this?

Greg Shenaut

[ Reply to This | # ]

Potential warning: 10.3.9 disables SUID/SGID flag
Authored by: timkingman on Apr 18, '05 04:48:44PM

No, you can't use chmod to set the setuid bit on any file. You can only do it on files you own, and thus an unprivileged user cannot create a setuid binary with escalated privileges as you describe. You can create setuid binaries that run as your own user all day long, and I'd hardly consider this a "much worse security problem."



[ Reply to This | # ]
Potential warning: 10.3.9 disables SUID/SGID flag
Authored by: gshenaut on Apr 18, '05 05:43:13PM
My point is that the change does not reduce security since it it trivial to get past it, and it may worsen security by creating the temptation to construct a general work-around which would, by its generality, open doors that are now closed.

Here's a ksh script I wrote called "shuid" that restores much of the previous functionality and does not, I think, reduce security:

#!/bin/ksh

LIBEXEC=$HOME/.libexec

err(){
    print -u2 "Err: $*"
    exit 1
}
if [[ "$1" = "" ]] ; then
    err "Usage: shuid script [user [group]]"
fi

if [[ ! -d $LIBEXEC ]] ; then
    set -e
    mkdir $LIBEXEC
    set +e
fi

mv $1 $LIBEXEC
chmod a+x $LIBEXEC/$1

cat >$1.c <<FIN
main(int c,char **v) {
    execv("$LIBEXEC/$1", v);
}
FIN

cc -o $1 $1.c
rm $1.c

U=0
G=0
if [[ "$3" != "" ]] ; then
    G=$3
fi
if [[ "$2" != "" ]] ; then
    U=$2
fi

sudo chown $U:$G $1
sudo chmod +s $1

exit 0
What this does is to hide the actual script away in the user's home directory and replace it with a binary compiled to do nothing but to call the script in its new home. It then sets executable and suid on the binary.

Greg Shenaut

[ Reply to This | # ]

Potential warning: 10.3.9 disables SUID/SGID flag
Authored by: kamath on Apr 18, '05 09:37:22PM

Why not just 'sudo script'?

You can even avoid passwords with NOPASSWD in the sudoers file.

This is not stupid, this has been the case in most unices for several years now. It has to do with a race-condition in the interpreter fireup sequence.

As for making it trivial to circumvent security, why not just log in as root? Or no root password? How about 'chmod u+s /bin/sh'? I've seen them all (I'm not kidding).

Look, the point of this is NOT to make it more difficult for end-users to do something, but to make it possible for knowledgeable people to "do the right thing", like writing wrapper scripts (which, by the way, is *EXACTLY* what sudo is -- it was written because every unix shop on the planet had a 'suid', '.root' or other 'give me root' programs (because no one should log in as root if they can avoid it, as there's no way to track who was root that way) -- a general 'run any script or program as root' program), without allowing "unauthorized" people to do Bad Things(tm). Of course, on a Mac, since it's GENERALLY single user, it's a non-issue. But if you have one admin on a mac, and several unpriviledged users, then setuid shell scripts could allow one of those non-priviledged users to become root -- A Bad Thing(tm). Go google it (try "setuid shell script race condition").

Now, having said all that, it turns out there's a pretty "simple" fix to this, which is to have the kernel pass an already open filedescriptor to the interpreter, which some unices have implemented.

However, to be completely honest, one should avoid setuid scripts as much as possible. You only need them for non-terminal (in the sense of tty terminal, not "Terminal", the mac terminal program (shame on them for calling it Terminal)) applications (as in "ways to do things", not as Mac OS X Applications), such as startup script (which is moot, since they run as root).

Here's the one example I had: I have a web application (php) which controls itunes. For a while (before I found A Better Way), I used a wrapper script so that the applescript would be called as the user running itunes instead of 'www'. (The Better Way, i.e., EASIER, was to run apache as that user, instead of www, since I'm lazy. The One True Way would be to use suexec or the like).



[ Reply to This | # ]