☰

sudoers 文件：仅允许 sudo 组执行某些二进制文件

tag-icon • tag-icon sudo
sudoers 文件：仅允许 sudo 组执行某些二进制文件

我正在尝试将 Ubuntu 19.10 安装上的 sudo 组限制为仅限特定类型的可执行文件。

sudoers 文件现在具有以下形式：

Defaults    env_reset
Defaults    mail_badpass
Defaults    secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification
root    ALL=(ALL:ALL) ALL

# Members of the admin group may gain root privileges
#%admin ALL=(ALL) ALL

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL) NOPASSWD: /usr/bin/apt,/usr/bin/apt-key,/usr/bin/apt-add-repository,/usr/bin/make

# See sudoers(5) for more information on "#include" directives:

#includedir /etc/sudoers.d

遗憾的是，程序仍然无法执行，并出现错误消息，例如apt update：

Sorry, user ubuntuuser is not allowed to execute '/usr/bin/env PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin apt update' as root on Ubuntumachine.

如果我添加/usr/bin/env到可执行列表我可以再次执行每一个和不仅使用 限制的命令列表sudo。

答案1

正如你所发现的，shell 别名使得您运行的每个命令都sudo通过 运行env，而不是直接运行。

在您编辑/etc/sudoers以限制组成员sudo可以运行的命令后，所有sudo命令都报告您无权运行env。因此，出于某种原因，每次您运行时，它都会尝试使用运行命令。此外，错误消息始终采用这种确切形式：sudo commandenv

Sorry, user ubuntuuser is not allowed to execute '/usr/bin/env PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin command' as root on Ubuntumachine.

env以这种方式使用是一种常见的技术使用sudo你的$PATH而不是其选项的值secure_path。一些用户定义了一个 shell 别名或 shell 函数，称为sudomake run 类似的东西。在 Bash 中，运行将显示命令可能意味着的所有内容，并首先显示 shell 选择的含义。（将只显示那一个。）sudo commandtype -a sudosudotype sudo

回想起来您定义的别名，您可以通过将别名更改为不使用来解决问题env。当然，完全删除别名也可以。

照这样说，我鼓励你考虑不是使用此sudoers配置，因为与默认配置相比，它没有任何安全优势。实际上，它比默认配置的安全性略差。

主要问题是，虽然你似乎有意

%sudo   ALL=(ALL) NOPASSWD: /usr/bin/apt,/usr/bin/apt-key,/usr/bin/apt-add-repository,/usr/bin/make

限制组成员sudo可以运行的命令，访问这些命令就足以执行任何操作。作为一个例子——这只是一个例子——小组成员sudo可以创建以下内容Makefile：

.PHONY: elevate
elevate:
    su -

然后运行sudo make将给出一个 root shell，其效果与成功以 root 身份登录相同。（或者su -可以用另一个命令替换，例如，visudo以便于重新编辑文件。或者它们可以从给出的 root shellsudoers运行。）visudosu -

这无法通过限制传递的参数来解决。在这种情况下，make它本身不接收任何命令行参数。

您允许组成员运行的其他命令sudo也足以获得对系统的完全访问权限。即使apt仅凭这些命令也足以让用户安装他们想要的任何软件，包括不来自任何已配置存储库 ( ) 的软件。制作自己的 .deb 包并不难，并且（除其他攻击方式外）.deb 包可以包含在执行安装时以 root 身份运行的脚本。apt install ./package.deb

还有 Polkit。如果这是一个桌面系统，Ubuntu 中的 Polkit 配置为允许组成员sudo以 root 身份运行任意命令：

pkexec command

尽管它默认配置为授予组成员能力sudo，pkexec但不受文件内容的影响sudoers。

这不是什么大问题，至少理论上是这样，因为你可以重新配置 Polkit。

我之所以说你的配置是较少的比默认安全就是您正在使用NOPASSWD。这意味着以组成员身份运行的任何程序都sudo可以以 root 身份执行任何操作，而无需任何用户交互。

的安全隐患NOPASSWD虽然很大，但有时被夸大了。毕竟，获得该sudo组成员运行的程序的控制权的攻击者已经可以设置一个假sudo实用程序（例如，借助别名或 shell 函数）并捕获用户的密码。这很可能会成功。但这很麻烦，而且不是即时的。NOPASSWD消除了这种麻烦。您可能决定要这样做，但我建议您仔细考虑风险，特别是如果这是一个多用户系统（听起来就是这样）。

sudo从你想允许组成员运行的命令中，听起来这些用户确实在管理系统中发挥着作用。这很有道理——毕竟，如果他们不这样做，他们可能就不是该sudo组织的成员。即使在您的sudoers配置的“精神”范围内，他们也可以启用任意存储库，在系统范围内安装任意软件，我猜想让他们make以 root 身份运行，这样他们就可以使用以下命令对从源代码编译的软件执行相同操作sudo make install。

如果您完全信任该组的成员sudo（或者可能只是您），但只是想让他们更难意外做错事，那么一种方法可能是为他们提供不属于该sudo组的单独帐户，以执行不需要他们sudoroot 权限的任务。

如果你不信任他们，那么就不太可能有技术解决方案。即使你进一步锁定他们的能力，也还不够。控制整个系统上存在哪些软件供所有用户使用的能力始终等同于以 root 身份执行任意操作的能力。

相关内容