True, a C-shell-based SUID script can be very insecure, though with a script this simple, all the user would have to do is make sure the PATH is set specifically. Or as the article states, this could also be done directly in perl, thus removing much of the insecurity overhead with Cshell scripts.

However, at least IMO, I would think that being able to set one 'program' to be SUID for a specific group of users is better than allowing one user SUDO access, as the former is more specific about what you are allowing. Say the box is a web dev box, as it appears, and you have teammember Bob on it would does script developement; Bob, while compentent, isn't fully trustworthy at least to your team, but management says he needs to be able to change web server configurations and restart the http server for him to work. Allowing Bob SUDO access to the box could be very very bad, if he truly is a problem. On the other hand, allowing Bob into the access group that can run the apache restart program via a suid bit, means that the only damage he can effectively do (besides erasing config files) is starting and stoping the web server; the rest of the box remains secure. In addition, if Bob's account was broken into by someone more malicious than Bob, and BOB had SUDO access, you could kiss your box goodbye; limiting what can be done via suid programs will prevent a total compramise of the box.

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com
||
"You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"It's not what you know, but knowing how to find it if you don't know that's important

Allowing Bob SUDO access to the box could be very very bad, if he truly is a problem. On the other hand, allowing Bob into the access group that can run the apache restart program via a suid bit, means that the only damage he can effectively do (besides erasing config files) is starting and stoping the web server; the rest of the box remains secure.

Either I miss somthing either you ignore that sudo can be configured to grant precise/limited access to some prog.

One of sudo's features that I like best is its
logging capability. Sure, it's easy enough to build user
logging into an SUID script, but with sudo you
don't have to; it's already there. No points for
guessing which method will lead to more logging being done.

Ok, I've seen versions of sudo (maybe thrown together for a specific system) that lack the fine grained control that the modern versions of sudo appear to have, and that turned me off to the use of sudo in favor of other fine-grained solutions.

But you and I both have the same message: security (in general, and in this case) means to only allow specific cases to be accepted, instead of denying general cases, as it's more likely to find a hole in those general cases that will break your security than in the former case. So if the original poster does use sudo, make sure to set up the sudo table as arhuman as indicated to make sure only those that need to restart apache have the ability to do so , and only that ability. And this would require no extra special script or the like, just the line that is above in the sudo configuration file.

-----------------------------------------------------
Dr. Michael K. Neylon - mneylon-pm@masemware.com
||
"You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"It's not what you know, but knowing how to find it if you don't know that's important