How to get shell script to run with root privs?

[Gino Castoldi_2]

Hi,

HP-UX 11.0

I want a non-privilege user to run a bourne shell script with root privileges so that the script can execute certain OS commands (cp)
and run an executable that's owned by root.

Is this possible?

10 points to any good answer.
Thank you
Gino

[Mark Greene_1 · Accepted solution]

get sudo from here:

http://hpux.cs.utah.edu/hppd/hpux/Sysadmin/sudo-1.6.7p5/

and install it on your system. You can give root priviledges on a per user and per command basis with auditing.

mark

[Robert Salter]

Mark's answer is on the money, use sudo.

[Gino Castoldi_2]

Hi,

The sudo utility sounds good.
Will setuid/sgid on the script do basically
the same thing?

The reason why I ask is that when I installed the binary for sudo (Sudo version 1.6.7p5) it couldn't perform the setuid/sgid
when I ran swinstall on that depot file.

10 points to any good answer.
Thank you
Gino

[Helen French]

Setting setuid/setgid on a *script* is a big security issue. If you really want to set it, remove read and write permission from world (others) or else you are at risk. The alternative is to create an application program that calls this script and then setuid/gid on that program.

For these purposes, I would say 'sudo' is better and safe.

[John Meissner]

Service Control Manager (SCM)

currently at version 3.0 SCM is what I use at my work to allow non-provildged users to issue certain commands as root. Sudo (as mentioned above) will also work.

SCM allows users to run tools as root and you can control what boxes and what tools then can run. for more info: http://www.software.hp.com/portal/swdepot/displayProductInfo.do?productNumber=B8339BA3.0

[Michael Schulte zur Sur]

Hi,

write a little c programme, which calls a script by system call. Compile it and setuid on the c executable.

greetings,

Michael

[Emil Velez]

How about the restricted sam builder. You can add the script to sam specify that it runs under root id and then give it and other elements of sam like routine taks and performance management to some selected users. This would allow you to control who can run it, log when it gets run (in sam) and run it with root without root suid bit set on the script itself.

[Bill Hassell]

The sudo package does not install correctly from the Liverpool archive. This is a known problem with the package. The installation package from http://hpux.connect.org.uk/ has exposed a bug in swinstall. The sudo binary must be set to 4111 but in the INFO file, the owner and group are both 0, rather than the more customary root and root. This produces the error messages:

...

* Installing fileset "sudo.sudo-RUN,r=1.6.6" (1 of 1).
ERROR: Unknown owner and/or group for file "/opt/sudo/bin/sudo".

SUID and/or SGID bit was not set.
ERROR: Failed installing fileset "sudo.sudo-RUN,r=1.6.6". Check the
above output for details.
...

The fix is to manually edit the depot (must use swcopy of the depot file into a local depot). Using vi, cd into the sudo depot, then:

- cd /catalog (ie, /var/sw/depot/catalog)
- cd sudo/sudo-RUN
- vi INFO
Under path: /opt/sudo/bin/sudo, change both owner and group from 0 to root. Now you can reinstall sudo successfully for 11.xx

Bottom line: NEVER use setuid scripts. They can be used to compromise and are forbidden in most Unix environments. With sudo, you can not only restrict who can run sudo, but the commands that are allowed for each user and even the parameters used in the command. And best of all, everything is logged.

[Michael Schulte zur Sur]

Hi Shiju,

as much as I know, you set setuid on a shell script all you want, it is ignored. I have tried it, at least on Tru64 Unix before.

greetings,

Michael

[Bill Hassell]

On HP-UX, you can set a script to 4755 permissions, owned by root and when run, the effective user ID will be root. HOWEVER, you can disable suid programs and scripts with the nosuid option in mount and fstab (recommended for ALL data directories, the /home mountpoint and /var and /tmp. Then, when you try to run the script, you'll get a message:

/tmp/xx: Setuid execution not allowed

Now the reason that your suid test on Tru64 failed is probably the same reason it will fail on most Unix flavors including HP-UX. The very first line in every script must be the loader directive, as in:

#!/usr/bin/sh

Without this directive, the suid bit will not take effect. But as stated before, suid scripts should never ba allowed to exist anywhere on a Unix system. It is impossible to make a script unreadable yet allow any user to run it. A script is interpreted code so the shell must be able to open and run it. Once a user sees the contents of an suid script, they can figure out ways to subvert the code.

[Helen French]

Hi Michael,

As Bill said, the script must be started with:

#!/usr/bin.sh (or your script shell directive). Otherwise the setuid will not have any effect on it.

[Helen French]

oops ..typo:

#!/usr/bin/sh

[Michael Schulte zur Sur]

Hi Shiju,

here the result of my try:
-rwsrwsrwx 1 root users 35 Dec 3 10:58 t10
# cat t10
#!/usr/bin/sh
ps -ef | grep pts/te
root 6366 781 0 Dec 1 pts/te 0:00 telnetd
operator 2202 2200 2 11:01:31 pts/te 0:00 grep pts/te
root 6391 6367 0 Dec 1 pts/te 0:14 keysh
operator 2201 2200 8 11:01:31 pts/te 0:00 ps -ef
root 6367 6366 0 Dec 1 pts/te 0:00 -sh
operator 2200 2188 3 11:01:31 pts/te 0:00 /usr/bin/sh /tmp/t10
operator 2188 6391 1 11:01:26 pts/te 0:00 -ksh

greetings,

Michael

[MarkSyder]

Hi Gino,

if you're going to use sudo, make sure you set it up to prevent users from switching user to root.

The instructions provided with it are pretty comprehensive, but this is easily overlooked.

Mark Syder (like the drink but spelt different)

[Bill Hassell]

Here is an easier way to demonstrate real-user, login name and effective user:

#!/usr/bin/sh
id
UNIX95= ps -o user,ruser,uid,args

Create this file in a directory that allows SUID programs to run. chmod 4755 filename, then:

/opt/test-suid
uid=103(blh) gid=20(users) euid=0(root) groups=200(reallybi)
USER RUSER UID COMMAND
root blh 0 ps -o user,ruser,uid,args
root root 0 telnetd -b /etc/issue
root blh 0 /usr/bin/sh /opt/xx

Now move the program to a mountpoint with nosuid as a mount option:

/tmp/xx: Setuid execution not allowed
uid=103(blh) gid=20(users) groups=200(reallybi)
USER RUSER UID COMMAND
blh blh 103 -sh
blh blh 103 ps -o user,ruser,uid,args
blh blh 103 /usr/bin/sh /tmp/xx

And also: NEVER use 777 permissions on anything. 99.9% of the time the file or directory will be eventually trashed by some mistake and in the case of an SUID script, a hacker can simply edit the file to insert vipw or some other important command to compromise the system!