使用CmndAlias ALL将永远不安全
有1000种service network restart不用做的跑步方式sudo service network restart。这是一个调皮的用户可能尝试的示例：
$ echo "service network restart" > /tmp/hax
$ chmod a+x /tmp/hax
$ sudo /tmp/hax
如果为用户提供ALL命令别名，然后尝试创建黑名单，他们将始终能够找到解决方法。将bash列入黑名单，他们将使用python。将python列入黑名单，他们将使用Perl。将Perl列入黑名单，他们将使用PHP。没有人想要！
如果你真的不想别人去做什么事情，你应该做的是托马斯说，创造的东西，他们的白名单是允许这样做。
设置例外白名单
在下面的底部附近可以找到一个小型白名单的示例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.
（实际上，手册页中的此示例是不安全的，可以利用它更改root的密码！有关如何操作，请参见下面的评论。）
我们可以尝试根据您的情况进行调整，以service向人员组提供所有命令，但排除与service network您有关的命令：
%staff ALL = /usr/sbin/service *, \
! /usr/sbin/service *network*, \
! /usr/sbin/service *NetworkManager*
（该ALL位置是指Host_Alias，而不是Cmnd_Alias-是令人困惑的吗？）
用户将无法运行sudo bash或sudo tee或sudo wget或sudo /path/to/malicious_script。如果您小心的话，可以将更多管理员命令列入白名单。只是具体一点！
注意：我*在network上面的单词前添加了“ before” ，以防万一service将来会在工具中添加无害标志。假设--verbose将来添加了一个标志，那么用户将能够运行以下命令：
$ sudo service --verbose network restart
因此，我们需要*在服务名称之前使用任何标志。一个缺点是，这可能会阻止您实际上并不介意用户运行的其他服务，例如称为safe-network或network-monitor也将被拒绝的服务。
允许用户使用组权限编辑文件
在下面，您可以找到各种尝试rnano，sudo以使用户可以编辑一个或多个文件。但是实际上，它们比应有的更复杂，更危险。
一个更简单，更安全的解决方案是更改要为其打开编辑权限的特定文件的组权限。以下是几个示例：
### 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
如果您需要更细粒度的控制（例如：仅3个用户，但不是所有职员的访问权限），则可以使用addgroup命令创建一个新组，并向其中添加几个用户。
允许用户通过以下方式编辑文件 sudo
该答案的其余部分用于调查sudo在尝试为用户提供灵活性时在配置中留下漏洞的难易程度。我不建议您执行以下任何操作！
如果您想授予用户编辑特定文件的权限，可以尝试使用rnano：
%staff ALL = /bin/rnano /etc/nginx/sites-available/host
rnano将只允许他们编辑指定的文件。这对于防止恶意用户编辑其他新贵服务（例如/etc/init.d/urandom）并向其添加将要运行的行非常重要service network restart。
不幸的是，我没有找到一种rvim充分限制的方法（用户仍然可以使用来打开任何文件:e），因此我们受困于nano。
不幸的是，允许用户编辑多个文件要困难得多。
让用户编辑多个文件（难度要比原来大）
1.不安全的方法
注意通配符！如果您提供了太多的灵活性（或任何灵活性），则可以利用它：
%staff ALL = /bin/rnano /etc/nginx/sites-available/* # UNSAFE!
在这种情况下，恶意用户将能够编辑任何其他新贵服务脚本，然后运行它：
$ sudo rnano /etc/nginx/sites-available/../../../any/file/on/the/system
（Sudo实际上阻止.并..扩展了该命令，但不幸的是没有扩展该参数。）
我希望这样的事情可能会起作用，但是仍然不安全：
%staff ALL = /bin/rnano /etc/nginx/sites-available/[A-Za-z0-9_-]* # UNSAFE!
由于sudo当前仅提供glob模式，因此*可以匹配任何内容 -它不是正则表达式！
（编辑：我确实考虑过您是否会遇到上述情况，因为下面没有子文件夹sites-available。我们确实要求在文件夹后匹配一个字符，并且/..在文件名后应该失败。但这不是可行的解决方案，因为它rnano接受多个参数。而且总的来说，这对于带有子文件夹的文件夹还是不安全的！）
即使我们没有子文件夹，也不包含任何包含/../的行，*仍然可以利用提供glob 的规则，因为它rnano接受多个参数（在上循环遍历它们<C-X>，并且该空间很高兴地被*glob 接受。
$ rnano /etc/nginx/sites-available/legal_file /then/any/file/on/the/system
2.推信封（最终还是不安全的）
那么，如果我们拒绝任何包含空格或试图到达的行/..怎么办？那么最终可行的解决方案可能是：
# 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.
我们接受文件夹“下”的所有内容，但也拒绝对rnano是否传递if /..或/.or /.排除使排除成为/..多余，但为清楚起见，我将两者都留了下来。）
我发现该文件夹/.需要排除，因为否则用户可以将文件夹本身作为目标。现在，您可能会认为rnano如果指向文件夹会阻塞，但是您错了。实际上，我的版本（2.2.6-1ubuntu1）开头是轻微警告，文件为空，然后<C-X>要求我输入要保存的任何文件名，从而打开新的攻击媒介！好吧，至少它拒绝覆盖现有文件（在我所做的一项测试中）。无论如何，由于无法使用sudo将子文件夹列入黑名单，因此我们必须得出结论，这种方法再次是不安全的。对不起用户！
这个发现使我怀疑nano'restricted'模式的彻底性。他们说，一条链只有最薄弱的一环才牢固。我开始感到sudo黑名单魔术师的组合，并且rnano可能不会比一连串的雏菊更安全。
3.安全但方法有限
球形非常严格-它们不允许我们多次匹配角色类。你可以提供多种文件编辑，如果您的所有文件名具有相同的长度（在这种情况下，host后面一个数字）：
%staff ALL = /bin/rnano /etc/nginx/sites-available/host[0-9] # SAFE
但是，如果要授予用户编辑各种文件的权限，则可能需要明确指定每个文件：
%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
请勿随时使用a*。有关原因，请参见上文第1.和2.节。切记：一小笔便会损害整个超级用户帐户和整个系统。
4.编写自己的参数检查器（现在，安全是您的责任）
我希望他们将来会增加对regexp的支持sudo；如果使用正确，它可以解决很多问题。但是我们可能还需要具有检查参数属性的功能（仅允许文件，文件夹或某些标志）。
但是有一种方法可以在sudo中创建灵活性。把钱递过去：
%staff ALL = /root/bin/staffedit *
然后编写您自己的staffedit脚本或可执行文件，以检查用户传递的参数是否合法，并且只有在执行请求时才执行。
networking和network-manager？另外，为什么您的用户有权sudo访问？除非您希望它们具有完整的root特权，否则不应该这样做。