8

I would like to allow a specific user to be able to sudo /sbin/iptables only.

I have a bash script which configures iptables. The problem is that configuring /sbin/iptables as sudoable is not enough - The script itself also has to be sudoable.

The problem is that that file could be edited by the user (he may change configurations there), giving him the ability to run any command as root.

What is the proper approach to this problem?

iTayb
  • 251
  • 2
    Am I missing something? Why can't you just edit /etc/sudoers and add username ALL=/sbin/iptables /sbin/whatever? – nico Aug 13 '11 at 05:51

4 Answers4

6

I can see two methods:

  1. Allow the user to use /sbin/iptables through sudo without restriction (which is something dangerous, this means you trust the user somehow), and run the script with the permissions of the user. The script will invoke sudo each time /sbin/iptables is needed. This is assuming the script execution will be quick, since some password input will eventually be required at regular intervals¹.

    • Advantage: you don't need to have any trust in the script.
    • Disadvantage: as already mentioned, allowing the user to use /sbin/iptables without restriction is something dangerous.
  2. Allow the user to call only the script through sudo.

    • Advantage: the use of /sbin/iptables is restricted by the script.
    • Disadvantage: the script must be flawless.

About the problem you mentioned: if the script is owned by let's say root and has usual permissions: rwxr-xr-x, others users cannot modify it, they can only execute it (eventually through sudo to obtain more privileges).

With solution 2, and in the case of shell scripts (compared to more robust binaries/programs), beware of environment variables and the several external factors that can modify the execution of your script. Check that your sudo configuration resets properly the definition of every potentially harmful variable.


1. In fact, sudo can be configured with NOPASSWD if needed.

4

From wikipedia:

setuid and setgid (short for "set user ID upon execution" and "set group ID upon execution", respectively)[1] are Unix access rights flags that allow users to run an executable with the permissions of the executable's owner or group. They are often used to allow users on a computer system to run programs with temporarily elevated privileges in order to perform a specific task. While the assumed user id or group id privileges provided are not always elevated, at a minimum they are specific.

Try something like this

stefan@linux-ulsk:/usr/bin> zypper up
Root privileges are required for updating packages.
linux-ulsk:~ # whereis zypper
zypper: /usr/bin/zypper /usr/bin/X11/zypper /usr/include/zypper /usr/share/zypper /usr/share/man/man8/zypper.8.gz
linux-ulsk:~ # chmod u+s /usr/bin/zypper
linux-ulsk:~ # exit
stefan@linux-ulsk:/usr/bin> zypper up
Retrieving repository ...

I could start zypper without being a root, what i couldn't before.

Be careful with setuid and setgid! Some book quote:

Never give shell scripts setuid permission. Several techniques for subverting them are well known.

sivic
  • 314
0

You could try changing the group owner of the file and adding your user to that group. Then you could chmod the file to assign group permissions which would allow you to do what you need.

It's a choppy solution but it would work.

nopcorn
  • 9,559
  • Sorry, but your answer is really unclear. Maybe you could add the names of the files and groups you are talking about. – Stéphane Gimenez Aug 13 '11 at 02:25
  • change the group of /sbin/iptables. add your user to that group. chmod /sbin/iptables to allow the group to execute the file. That would work wouldn't it? – nopcorn Aug 13 '11 at 03:35
  • 1
    Essentially, you create a new group just for the user and give execution permission for iptables to that group. – nico Aug 13 '11 at 05:46
  • This answer is confusing, and is not related with the OP question. It is just useless to prevent other users to execute the script (as long as they are not granted elevated privileges by sudo). – Stéphane Gimenez Aug 13 '11 at 10:12
  • @Stephane - The op said he wanted to grant permissions to that user only (see first sentence). I took that as a restriction. – nopcorn Aug 13 '11 at 11:26
0

Make sure that you (or an appropriate account) are the owner of the file, and make the file only writable by you, not by the group. So your permissions would be something like 750, assuming that your user is in the correct group.

If they can execute but not write the file, then you're safe to add that command to their sudo list.

  • The reason I suggested changing the group instead of the owner is that chances are root owns that file and changing the user might cause conflicts somewhere else. – nopcorn Aug 13 '11 at 03:36