I have a script that I want some of my users to be able to run that requires admin. Of course I don't want to give them admin privileges. How do I allow this script to run in a secure way?
Update: This is a Ubuntu 9.10 system.
Add a comment
|
4 Answers
Just use sudo. You need to configure sudo in /etc/sudoers, something like this:
fred ALL = (root) NOPASSWD: /path/to/command
Replace fred with the username, or use %group for a group. If you remove the NOPASSWD: option then they will be prompted for their password each time.
setuid on a script is insecure and won't work on Linux.
-
Thanks, I didnt know sudo was this versatile. Maybe you could update your answer with more specific instructions for people that have this question in the future? Jan 25, 2010 at 19:11
-
-
1Just be wary of anything run by the script that allows access to a shell escape - such as vi/vim. Jan 26, 2010 at 5:24
sudo and SUID are both very insecure. It's possible - and, depending on the scripting language, easy - to escape out of either of them. SUID is by far the worst, and some scripting languages won't even run if that's done.
I have a blog post on how to do it securely, which I first wrote for running Nagios check plugins as root but is perfectly applicable here. There's a small C program (that's been floating around the Linux admin world for years) that just acts as a wrapper around the script. You just edit the C program source to include the full path to the script, compile it, and then set that SUID (or give sudo access to that). The source is on my site: setuid-prog.c.
The inherent problem with running scripts as root (for non-root users) is that in many languages, using a variety of techniques (from poor input checking to overflows) it may be possible to break out of the running script and get full root access. Many old-time Unix guys recommend just writing a C program to do what you need - but then again, most of them were SAs when you needed to be able to write C competently.
-
Very interesting. Its not really a problem in my case because I trust my users with root, they just don't have the skill to use it properly. Thanks for the information though. Have you ever used the shc script compiler? Edit: Wouldn't it be possible to modify the data section of the executable and replace the #defined path with whatever you want? Jan 26, 2010 at 16:41
-
Nevermind. For some reason I spaced that the executable would be read only to the user. Jan 26, 2010 at 16:49
On which OS?
On Linux/Unix you can allow them to run it via sudo. The /etc/sudoers file can be modified to grant them specific permissions on designated commands, to certain IDs (users).
Alternatively, you can set the SUID bit on it, and change the script to be owned by a privileged user. That would set the script to run as that user, rather than the user running it. However, that is for all users running it.
-
2
-
Well, that's why my preference would be sudo, which is designed for the task. SUID is a bit (very) messy in this case, giving waay more access to everyone. And, potentially someone can change the script and run anything with elevated permissions.– AlexJan 25, 2010 at 19:48
There are two ways:
The best is to set the SUID bit on it: chown root yourscript; chmod a+s yourscript.
Alternatively, you can give them access to modify it using sudo, by running visudo and following the instructions. However, this is unnecessary, as this works by them running sudo, which has the SUID bit.
-
1
-
-
1It is long-standing advice; it may be less critical now than it used to be. Basically, there are (and definitely were) too many ways of subverting a script. Infamously, one way was to set IFS="/" (and ensure that PATH was set appropriately); this made it easy to execute commands that the script writer did not expect, especially annoying if they'd gone to the effort of specifying /bin/rm and so on. That no longer works; there are likely to be other equivalent but more devious ways to subvert scripts. Be extremely cautious! Jan 26, 2010 at 5:27