How to prevent sudo users from running specific commands?

Solution 1:

Using CmndAlias ALL will never be safe

There are 1000 ways to run service network restart without doing sudo service network restart. Here is an example of what a naughty user might try:

$ echo "service network restart" > /tmp/hax
$ chmod a+x /tmp/hax
$ sudo /tmp/hax

If you provide users with the ALL command alias, and then try to create a blacklist, they will always be able to find a way around it. Blacklist bash, and they will use python. Blacklist python, and they will use Perl. Blacklist Perl, and they will use PHP. Nobody wants that!

If you really don't want someone to do something, you should do as Thomas says, and create a whitelist of things they are allowed to do.

Setting up a whitelist with an exception

An example of a small whitelist with an exclusion can be found near the bottom of man sudoers:

 pete           HPPA = /usr/bin/passwd [A-Za-z]*, !/usr/bin/passwd root

The user pete is allowed to change anyone's password except for root on the HPPA
machines.  Note that this assumes passwd(1) does not take multiple user names
on the command line.

(In fact this example from the manpage is unsafe and can be exploited to change root's password! See the comments below for how.)

We can try to adapt that to your case, to offer all service commands to the staff group, but exclude the service network commands that concern you:

%staff ALL =   /usr/sbin/service *,                            \
             ! /usr/sbin/service *network*,                    \
             ! /usr/sbin/service *NetworkManager*

(The ALL in that position refers to the Host_Alias, not the Cmnd_Alias - confusing isn't it?)

The user won't be able to run sudo bash or sudo tee or sudo wget or sudo /path/to/malicious_script. You can whitelist more admin commands for your users if you are careful. Just be specific!

Note: I added the * before the word network above, just in case a harmless flag is ever added to the service tool in the future. Let's imagine a --verbose flag was added in future, then users would be able to run the following:

$ sudo service --verbose network restart

So we need the * to consume any flags before the service name. The one disadvantage is that this might block other services which you don't actually mind users running, e.g. a service called safe-network or network-monitor would also be rejected.

Let users edit a file using group permissions

Below you can find various attempts using rnano through sudo to let users edit a file or files. But really they are more complex and more dangerous than they should be.

A much simpler and safer solution is to change the group permissions on the specific files that you want to open edit rights for. Here are a couple of examples:

### Give steve the ability to edit his nginx config:
$ chgrp steve /etc/nginx/sites-available/steves_dodgy_project
$ chmod g+rw /etc/nginx/sites-available/steves_dodgy_project

### Let all members of the staff group edit the group_website config:
$ chgrp staff /etc/nginx/sites-available/group_website
$ chmod g+rw /etc/nginx/sites-available/group_website

If you need more fine-grained control (for example: access for just 3 users, but not all staff members) you can create a new group using the addgroup command, and add just a few users to it.

Let users edit a file through sudo

The remainder of this answer became an investigation into how easy it is to leave holes in your sudo configuration when trying to offer flexibility to your users. I would not recommend doing any of the following!

If you want to grant your users access to edit a specific file, you could try using rnano:

%staff ALL = /bin/rnano /etc/nginx/sites-available/host

rnano will only let them edit the file specified. That is important to prevent a malicious user from editing a different upstart service (for example /etc/init.d/urandom), and adding a line to it which would run service network restart.

Unfortunately I did not find a way to restrict rvim sufficiently (the user can still open any file using :e), so we are stuck with nano.

Unfortunately allowing users to edit multiple files is much harder...

Let the users edit multiple files (way more difficult than it should be)

1. Unsafe approaches

Be careful of wildcards! If you offer too much flexibility (or any flexibility), it can be exploited:

%staff ALL = /bin/rnano /etc/nginx/sites-available/*                # UNSAFE!

In this case, a malicious user would be able to edit any other upstart service script, and then run it:

$ sudo rnano /etc/nginx/sites-available/../../../any/file/on/the/system

(Sudo does actually prevent . and .. expansion on the command, but unfortunately not on the arguments.)

I was hoping something like this might work, but it is still insecure:

%staff ALL = /bin/rnano /etc/nginx/sites-available/[A-Za-z0-9_-]*   # UNSAFE!

Since sudo currently only offers glob patterns, that * will match anything - it is not a regexp!

(Edit: I did consider if you might get away with the above in your situation, because there are no sub-folders beneath sites-available. We did demand one char be matched after the folder, and /.. should fail after a filename. However this is not a workable solution, because rnano accepts multiple arguments. And anyway in general this would still be unsafe on a folder which had subfolders!)

Even if we have no subfolders, and we exclude any lines containing /../, the rule offering a * glob could still be exploited, because rnano accepts multiple arguments (cycling through them on <C-X>, and the space is happily accepted by the * glob.

$ rnano /etc/nginx/sites-available/legal_file /then/any/file/on/the/system

2. Pushing the envelope (also ultimately unsafe)

So what if we reject any lines containing spaces, or attempting to reach /..? Then a final workable solution might be this:

# I tried hard to make this safe, but in the end I failed again.
# Please don't use this unless you are really smart or really stupid.

%staff ALL =   /bin/rnano /etc/nginx/sites-available/*,    \
             ! /bin/rnano */..*,                           \
             ! /bin/rnano /etc/nginx/sites-available/,     \
             ! /bin/rnano */.,                             \
             ! /bin/rnano * *

# CONCLUSION: It is still NOT SAFE if there are any subfolders, due to
# the bug in rnano described below.

We accept anything "under" the folder but we also reject any call to rnano if /.. or /. or are passed, or if the folder is targeted directly. (Technically the /. exclusion makes the /.. exclusion redundant, but I have left both in for clarity.)

I found the folder and the /. exclusions were needed because otherwise the user could target the folder itself. Now you might think rnano would block if pointed at a folder, but you would be wrong. Actually my version (2.2.6-1ubuntu1) starts up with a mild warning and an empty file, then on <C-X> asks me to input any filename I like to save to, opening a new attack vector! Well at least it refused to overwrite an existing file (in the one test I did). Anyway, since there is no way to blacklist subfolders with sudo, we must conclude that this approach is again unsafe. Sorry users!

This discovery made me doubt the thoroughness of nano's "restricted" mode. They say a chain is only as strong as its weakest link. I am beginning to feel the combination of sudo blacklist black-magic and rnano may be no more secure than a chain of daisies.

3. Safe but limited approaches

Globs are very restricted - they don't let us match a character class multiple times. You could offer multiple file edits, if all your filenames have the same length (in this case host followed by a single digit):

%staff ALL = /bin/rnano /etc/nginx/sites-available/host[0-9]       # SAFE

But if you want to give the user access to edit various files, you may need to specify each and every file explicitly:

%staff ALL = /bin/rnano /etc/nginx/sites-available/hothost    \
             /bin/rnano /etc/nginx/sites-available/coldhost   \    # SAFE
             /bin/rnano /etc/nginx/sites-available/wethost    \
             /bin/rnano /etc/nginx/sites-available/steves_dodgy_project

Do not be tempted to use a * at any point. See sections 1. and 2. above for why! Remember: one small slip can compromise the whole superuser account, and the whole system.

4. Write your own argument checker (safety is now your responsibility)

I hope they will add regexp support to sudo in the future; it could solve a lot of problems if used correctly. But we may also need the ability to check the properties of arguments (to allow only files, only folders, or only certain flags).

But there is one alternative to create flexibility in sudo. Pass the buck:

%staff ALL = /root/bin/staffedit *

Then write your own staffedit script or executable to check if the arguments passed by the user are legal, and only carry out their request if they are.

Solution 2:

First, open the sudoers file with sudo visudo. Adding user ALL=!/usr/sbin/service will, IIRC, disallow the service command for user user.

Sources: http://nixcraft.com/showthread.php/15132-Sudo-Exclude-Commands-And-Disable-sudo-su-Bash-Shell

Solution 3:

I have found the solution.

I have opened terminal and change into root user with su - then I have typed visudo to edit.

then at the end I have written lines like

user ALL=!/etc/init.d/NetworkManager restart
user ALL=!/etc/init.d/network restart

Then I have save & closed and restarted too.

Now If I am typing as service network restart or service NetworkManager restart then its not allowing me and giving an error like

Sorry user is not allowed to execute '/sbin/service NetowkrManager restart' as root on localhost.localdomain

and similarly for service network restart command also.

Solution 4:

The real answer to this is that you can't really prevent this. You might prevent someone unmalicious from accidentally running that command via the methods described in the other answers, but if someone really wants to run it and is on the sudoers list, they can run it. For example, they could do the following:

joe@box:~$ sudo bash root@box:~# service network restart

Or another fun command they could use to circumvent your restrictions in the sudoers file:

sudo visudo

Long story short, if you can sudo and it isn't restricted to running particular commands, you can do pretty much whatever you want. Even if you restrict them to a given set of commands, you'd have to make sure that it isn't possible for the user to copy some other command that they wanted to run to the same name as one they had permission to run (such as by overwriting the command that they have permission to run.)