32

I have a very sensitive network setup and I really dont want to mess up with it. My network consists a bunch of users who are with sudo privilege.

I want to stop them from running

service NetworkManager restart
service network restart

commands.

Is there any way I can achieve this?

6
  • Which distribution are you using? The service names are distro specific and I don't know of any distro that uses the names you have there. Do you mean networking and network-manager? Also, why do your users have sudo access? They shouldn't unless you want them to have full root privileges.
    – terdon
    Mar 29, 2014 at 17:27
  • @terdon I have solved it. Thank you. I cant post it as answer because I am a new user
    – shekhar
    Mar 29, 2014 at 17:56
  • Yes you can, please do. I'd also like to know the answer you found.
    – terdon
    Mar 29, 2014 at 17:57
  • @terdon sure but its saying I need to wait for 8 Hrs to post my own answer because I dont have even 10 reputation
    – shekhar
    Mar 29, 2014 at 17:58
  • 1
    Ah, yes, sorry, you do indeed need to wait. I just upvoted, you have the rep now :)
    – terdon
    Mar 29, 2014 at 18:01

5 Answers 5

53

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.

7
  • 5
    This answer took a long time, but finally I think I understand how sudo works. I gave up on various occasions in the past, finding ALL=(ALL:ALL) ALL too lacking in semantics, but I always assumed somewhere it would have a decent argument checker... I was wrong. It's really very limited. Even the passwd root exclusion offered in the man-page can be broken with a simple command-line argument, sudo passwd -q root. Well the sudo authors do list [some alternatives](sudo.ws/sudo/other.html) on their website. I hope they will add regexp support in future. Mar 29, 2014 at 23:59
  • Do you specifically use rnano in your description here because it's a version of nano that lacks a 'save as' function? I'm not familiar with the program. Mar 30, 2014 at 7:56
  • Yes. If we care about security, the editor should only edit the one file specified, and should not be able to open a shell. For info, $ man nano then /-R<Enter> Mar 30, 2014 at 8:00
  • Correction: To break the pete example, the -q must come afterwards: sudo passwd root -q. The pete example can be hardened by excluding *root*. Feb 17, 2016 at 11:16
  • 1
    @HCSF well, sudoedit allows you to use any text editor you like, because it makes a temporary user writable copy of the file to be edited, and if the file is modified within the editor, when quitting, it it overwritten on the filesystem, using sudo privileges. I'm just suggesting another option :), not saying that joeytwiddle's answer is not valid though.
    – Totor
    Feb 18, 2021 at 22:30
5

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

6
  • This will stop running other services too and I dont want that. Thanks for the answer. :)
    – shekhar
    Mar 29, 2014 at 17:15
  • while your answer not helped me exactly but its helped to dig out a solution thank you. but you know either to give you upvote or post my working answer I dont have enough reputation. I will surely give my thanks once I am . Thank you.
    – shekhar
    Mar 29, 2014 at 17:58
  • 2
    Yeah, but still, like others have stated, you have to be very careful with that. There are many ways on how to gain access. Any command that could spawn a shell and so on. Its way easier to figure out what commands they really need and allow them, instead of trying to exclude all of the "forbidden" ones. Mar 30, 2014 at 6:39
  • 3
    Whitelists are unmaintainable in many scenarios. The real goal may not be to prevent them from doing something, but rather, to keep them from doing something bad by mistake without otherwise restricting them. Blacklists are good in these cases. You blacklist the ways a reasonable user would go about the task. But blacklisting via sudo may not be sufficient -- people can and do use 'sudo bash'. One approach would be to wrap the 'service' command, and in the cases you don't want them to use, inform them. But you'll never list all good actions in a whitelist, nor all bad ones in a blacklist.
    – Bob Kerns
    Mar 30, 2014 at 8:00
  • 1
    I agree with you Bob. To allow flexibility, without allowing full access, you will often need to roll your own solution, as a helper script, and whitelist only that script. sudo whitelists might do what you need, but often they will be either too limited, or too easy to exploit. Mar 30, 2014 at 8:31
5

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.

3
  • 14
    That will work for unexperienced and unmalicious users, but it is easy to circumvent sudo restrictions, (e.g. sudo cp -p /etc/init.d/network /etc/init.d/network-not-in-sudo and then sudo /etc/init.d/network-not-in-sudo restart). Which is why it is far safer to create inclusions instead of exclusions in the sudoers file, e.g. state which services they are allowed to interact with.
    – Thomas BDX
    Mar 29, 2014 at 19:28
  • Everything that 'service network restart' does, you can do with other commands, such as the ones in the network init.d script. I won't even try to list them here. But if you want, for example, to actually prevent modifications of interface state, then an SELinux policy seems to me to be the way to go. It's a complex topic, but when a whitelist is too restrictive or burdensome, and a blacklist is inadequate, it's probably your best option. It's implemented in the kernel, and allows you to restrict access to network interfaces (and other resources) even to sudo'd users.
    – Bob Kerns
    Mar 30, 2014 at 8:32
  • If it is possible with SELinux then It would be more pleased. @BobKerns Thank you. I will try in that way.
    – shekhar
    Mar 30, 2014 at 18:02
5

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.)

2
  • Yeah. One should avoid commands that can spawn a shell from within. Mar 30, 2014 at 6:33
  • 1
    The problem is, it's not commands you want to protect, but the state of kernel objects, such as routing tables, interfaces, etc. -- no matter what command (or system call) is used. And you want to protect it from some, but not all, root users. SELinux is designed around this sort of scenario. But first, I would start with a review of why all these users have sudo access. If they only need to do a few specific things, whitelisting operations in sudoers may be all you need.
    – Bob Kerns
    Mar 30, 2014 at 8:56
3

Use firejail to restrict users with sandboxes.

https://github.com/netblue30/firejail/

Set firejail as shell instead of bash in /etc/passwd, for every user you want to restrict. It is very easy to use and has a good documentation.

Example:

user:x:1000:1000:user:/home/user:/usr/bin/firejail

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .