[sudo-users] restrict shell out to root using sudo
mhabib73 at gmail.com
Sat Jul 10 23:20:38 EDT 2010
Thanks very much and I appreciate your valuable input. This will help me to
finalize our sudo procedures and control for application team.
On Sat, Jul 10, 2010 at 1:51 PM, <highc at stny.rr.com> wrote:
> 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.
>> , 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
> rm /tmp/$$.tmp
> 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.
> rm /tmp/$$.tmp
> 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.
> sudo-users mailing list <sudo-users at sudo.ws>
> For list information, options, or to unsubscribe, visit:
This communication contains confidential information intended only for the
persons to whom it is addressed. Any other distribution, copying or
disclosure is strictly prohibited. If you have received this communication
in error, please notify the sender and delete this e-mail message
Le présent message contient des renseignements de nature confidentielle
réservés uniquement à l'usage du destinataire. Toute diffusion,
distribution, divulgation, utilisation ou reproduction de la présente
communication, et de tout fichier qui y est joint, est strictement
interdite. Si vous avez reçu le présent message électronique par erreur,
veuillez informer immédiatement l'expéditeur et supprimer le message de
votre ordinateur et de votre serveur.
More information about the sudo-users