[sudo-users] restrict shell out to root using sudo
highc at stny.rr.com
highc at stny.rr.com
Sat Jul 10 13:51:53 EDT 2010
Muhammad Habib wrote:
> I am looking for restricting users to do shell out in their scripts. [...] I tried to stop it using "NOEXEC" function but that
> will cause this script1 to run OK , but all commands in this script (eg. ps
> , uname etc.) will fail to run as well.
> script1 is as follows:
> uname >> /tmp/myhost
> ps -ef | grep db >> /tmp/myproc
Todd's right, there's no way to stop someone from running arbitrary
commands; however, you can consider instead authorizing them to run the
commands withing the script; for instance...
cp /tmp/myhost /tmp/$$.tmp
uname >> /tmp/$$.tmp
sudo cp /tmp/$$.tmp /tmp/myhost
cp /tmp/myproc /tmp/$$.tmp
ps -ef | grep db >> /tmp/$$.tmp
sudo cp /tmp/$$.tmp /tmp/myproc
Then you authorize them to run sudo for cp, with as tight as possible
definition, instead of the script. Modifiction of the script is less
problematic since they can change 'details' around how the script can
run, but cannot introduce any commands to run with root authority they
are not already authorized to run. You may need to set the sudo
authorization with 'NOPASSWD' for the command, depending on how long the
script might run, etc.
Of course, you still need to trust this person, as there's some very
unpleasent things they can do with cp as allowed above; but it has to be
less risk than allowing them to run arbitrary commands.
I know we are using this as 'just an example', but it seems to me the
simplest solution here is to assign the user to a group; and give that
group write authority to /tmp/myhost and /tmp/myproc.
For example, say someone wants to be able to take a snap shot of how
full -all- file systems are, now and again.
sudo df -k > /tmp/$$.tmp
date >> /tmp/collected.df
cat /tmp/$$.tmp >> /tmp/collected.df
# do some processing on the file /tmp/$$.tmp
# For instance, send an alert if a filesystem is over 90% full.
You assign a particular group to be able to update /tmp/collected.df
(presumably so someone debugging full file systems can see any
historical data); the only thing in the script they need root authority
for is 'df', so you authorize -that-. The rest of the invokation
doesn't need root authority, so you don't have them run as root... much
safer. (df can sometimes require root authority (or more authority than
a particular user has) depending on the ownership/access rights on the
mount points.) If they need to modify the script, it's not a big deal
since all you really have done is give them the authority to run df.
Good luck... Chris.
More information about the sudo-users