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
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*
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
network-monitor would also be rejected.
Let users edit a file using group permissions
Below you can find various attempts using
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
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
%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
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
.. 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!
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
$ 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
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 \
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.
network-manager? Also, why do your users have
sudoaccess? They shouldn't unless you want them to have full root privileges.