New Messages

Please send letters via email to saletter@mfi.com.

I received several messages regarding Ed Schaefer's article "Sybaccess: A Menu-Driven Interface to Sybase" in the July issue - all pointing out a mistaken reference to the sticky bit. Here are two letters that set the matter straight. Thanks to everyone else who wrote in. - AA

Topic: Correction
I would like to make a correction to a short article in your July 1996 issue, p. 52. In the box titled: "The Sticky Bit and Sybaccess," the bits in question are NOT called "sticky bits"... they are called the "set-user-ID-bit" and the "set-group-ID-bit," respectively. The "sticky bit" is the last bit in that set and when it is set, it appears as a "t" in the last column of the permissions.

Originally used to force the storage of frequently used programs in local memory or swap (make them "stick"), it has lately been used on directories with 777 permissions (like /tmp) to keep other people from deleting files they do not own. In fact, having the "sticky bit" set on /tmp is a security requirement of mine.

It can be set by this command:

chmod 1777 /tmp

Please tell your writers to keep their nomenclature straight.

Thanks!
Shel Randall
Thank you for bringing it to our attention. Here's the long version...

-AA

To: Ed Schaefer
I flipped through the latest Sys Admin and saw your Sybase article. I don't use this database at all, but I did see the sidebar on the "sticky bit," and I have to say that it needs a bit of revision.

First, it's not the sticky bit you're talking about here, it's the setuid/setgid bits. The sticky bit was found in older, non-demand-paged environments (Sys V Rel 2, for instance) that told the OS to keep a program loaded in RAM even after the last user was finished with it. This way when the next user ran the program, it was already loaded.

However, suggesting that people write setuid programs like this is so unbelievably dangerous that you simply cannot even suggest this in a published article. The security implications here are such that there are a hundred ways to beat this.

1) $ cd /tmp
$ cp /bin/sh sybaccess
$ /usr/local/bin/runsybaccess
#

You fix this by putting the full path in the system() call:

2) $ cd /tmp
$ cp /bin/sh tput
$ PATH=/tmp:$PATH /usr/local/bin/runsybaccess

Now, when tput clear kicks in, it runs my program instead of yours. I might have to use a script instead of /bin/sh, but that's a minor issue.

So, you fix the script and put an explicit $PATH at the very front of it to forestall this kind of thing.

3) $ cd /tmp
$ SHELL=/tmp/myprogram /usr/local/bin/runsybaccess

Now, when it forks a shell to run your program, it uses my shell instead (not many UNIXs are susceptible to this, but some are).

You fix this so that it does a putenv("SHELL=/bin/sh") before doing the system() call.

4) $ cd /tmp
$ cp /bin/sh usr <- yup, "usr"
$ PATH=/tmp IFS=/ /usr/local/bin/runsybaccess
#

The shell uses $IFS to break apart its inputs into "words," and normally it's space+newline+tab. By setting IFS to /, the command it runs is "usr" with "local" "bin" "sybaccess" as arguments. Since it's looking on my path - even if $TMP is at the end - it will run my program.

The difficulties go on and on.

Creating a setuid root front-end is so fraught with troubles that you have to be exceedingly skilled at getting it right (say, like me) to even do this, and then you must have a very healthy disbelief in your own skills.

I have done a number of setuid front-ends, and none of them runs as root for very long. These programs (which are very small and therefore easy to verify) do their limited business as root and then revoke their root permissions before running the user's program directly. Then, with the no-root-permissions the security issues become much less.

A much better solution to most of these issues is running set *group* id, but that's another topic.

So, be very careful when you suggest to others that they do this kind of thing. If you're in an environment with all trusted users (say, your office) you can do this knowing that it does not need to be secure - why break root when you already have it? But, I am certain that people will be burned by this if they don't know the risks.

Steve Friedl

I should have been more adamant about discouraging the use of this possible security hole. You definitely plugged it. I think I've been properly chastised on this one, but also by readers Matthew Cheek, Shel Randall, and Alex Ostapenko.

Ed Schaefer