Setuid scripts

[SAM_24]

Hi,

People says using setuid scripts are security hole.Can anyone explain how?

Thanks.

[harry d brown jr]

It's like hiding the key to your front door under the welcome mat.

In general it's just a bad idea, but it's not criminal. You need to be "selective" as to what you do and don't set the uid on.

live free or die
harry

[Umapathy S]

hi,

Setuid scripts are always a security hole. Read the whole question at comp.unix.questions.

http://www.cs.uu.nl/wais/html/na-dir/unix-faq/faq/part4.html

HTH,
Umapathy

[Michael Steele_2]

'setuid' means owned by root but executable to the world. For example:

-r-sr-xr-x 31 root sys 544768 Jul 20 19:07 lvcreate

The above 'lvcreate' command is owned by 'root:sys' but the setuid bit '-r-s' is set.

Do you want commands like 'shutdown' to be world executable or have scripts that can be modified and rerun that have 'setuid' embedded within?

Say you've got a cron that goes off and its modified with the above command. The culprit who was once unable to shutdown the server because he didn't have root, now can.

Here's how you 'setuid' is set:

chmod 4--- /usr/sbin/shutdown

[twang]

Setuid script is really a security problem.
If we set the setuid bit on a script that is owned by user_a. Then anyone who has execute permissions on the script would run it as user_a.
The problem is if users have "write" permission or they can append codes to the script.
Therefore don't allow them to write or put their own code into the script.

For such purpose of setuid, I prefer to start the process directly as the user. And I think we should stay away from using setuid scripts because it is just a bad habit.

[Bill Hassell]

With extraordinary procedures inside the script (extensive parameter checking, 100% trap checking), a setuid script can be "safer". The problem is that a script must always be readable to run (execute without read permission won't work) and a hacker can then view the contents of the script, looking for opportunities. Let's take a script that just does a mount or umount of a CDROM. Without a carefully designed trap, a hacker could start the script, then break out of the script to get a shell prompt. However, the effective user ID would be root and now the hacker has access to all root-only commands. (the details are purposely omitted).

Similarly, a script might copy some files as root but without filename checking, a hacker could specify a replacement password file and copy their own version on top of /etc/passwd. There are other hacks including setting an unsecure PATH variable (the script forgot to replace $PATH with a known list), setting IFS, and a bunch of other hacks that are widely known and documented.

Don't ever create a set UID script! Use sudo and put appropriate checks in place to prevent problems. Or write all set UID code as an executable problem in C or FORTRAN, etc. You still need security checks inside executable programs too.