如何保护 sudo 驱动的脚本

Question

以非特权用户身份执行 root 命令的解决方案 - sudo 'ing 脚本- 很容易导致安全漏洞和意外行为和结果的可能性（这对于任何其他解决方案也是如此，例如带有 的二进制包装器setuid）；

很明显，脚本是使用 visudo 添加的，就像这样

www-data ALL=(ALL) NOPASSWD: /usr/local/sbin/mycommand

• 应该只能由 root 用户可读、可写和可执行- 这既是所有者又是组 ( chown root:root mycommand; chmod 700 mycommand)
• 应该有它的父目录的所有权 root:root与755模式
• 应验证输入- 参数和标准输入 - 并拒绝并中止提供的任何无效/意外数据的执行
• 应该使用绝对而不是相对路径/别名（？）
• Defaults env_resetin/etc/sudoers应该设置（？这里需要帮助）

还可以做些什么来保护 sudo 驱动的脚本？

Answer 1

我会稍微修改一下保护脚本的标准列表。鉴于此 - 或类似 - 条目/etc/sudoers：

www-data ALL=(ALL) NOPASSWD: /usr/local/sbin/mycommand

我们可以声明脚本：

• 必须只能由 root 用户写入
• 必须是 root 用户可读和可执行的
• 必须位于只能由 root 写入的目录层次结构中
• 必须“充分”验证其输入以供使用，并拒绝其他任何内容
• 应该具有执行其任务所需的最小权限集（不一定是 setuid root）
• 应该PATH在使用任何外部命令之前定义它
• 应在使用前将所有变量设置为已知值
• 应该生成一个审计跟踪，不仅显示它被调用的时间和方式，而且显示产生的操作（想想logger）

此外，在许多情况下，脚本实际上并不需要以 root 身份运行——它可以运行 setgid，甚至可以将 setuid 运行到某个其他帐户。在一般情况下，请考虑这些选项以避免授予对脚本的完全 root 访问权限。

对于 SELinux 环境，可以创建一个策略来防止脚本执行任何意外操作。CAP_NET_ADMIN 之类的功能比全面的 root 权限更精细，也可能值得考虑。

在您概述的特定情况下，您想要验证单个 IPv4 地址并将其传递给iptables，您可能能够将 IP 地址验证为一系列非特定八位字节。在这种情况下，444.555.666.999 可能被认为是合理的，因为它知道它iptables自己会拒绝任何不是真实 IP 地址的东西。在一种极端情况下，您可能会认为匹配 RE/^[0-9.]+$/足以将值传递给iptables. 另一方面，StackExchange 和其他地方有很多解决验证 IP 地址问题的答案。有些比其他的好。

要考虑的特殊情况是 RFC1918 地址、多播地址和您自己的外部 IP 地址范围。哦，还有以前称为 E 类的保留块。您需要 IPv6 支持吗？

如果您的脚本每分钟被调用数百次会发生什么？您需要为这种情况做好准备吗？你的iptables链条会溢出吗？如果你认为你会需要数百条规则在链将是[更有效地使用ipset扩展到iptables而不是一个线性表。这是一个很好的教程。在保护方面，它允许您构建数千个（如果不是数万个）类似规则集，这些规则集可以运行而不会显着减慢流经您的规则集的流量。

突然之间，您看似简单的要求变得相当复杂。

Answer 2

最好的事情之一是使用文件中的“Digest_Spec”可能性sudoers，以验证可执行文件的校验和

手册页摘录：

如果命令名称以 Digest_Spec 为前缀，则只有在可以使用指定的 SHA-2 摘要进行验证的情况下，该命令才会成功匹配。

使用 openssl，生成校验和：

$ openssl dgst -sha224 /usr/local/sbin/mycommand
 SHA224(/usr/local/sbin/mycommand)=
         52246fd78f692554c9f6be9c8ea001c9131c3426c27c88dbbad08365 

然后在你的 sudoers 文件中（在同一行）：

 www-data ALL=(ALL) NOPASSWD: 
    ssha224:52246fd78f692554c9f6be9c8ea001c9131c3426c27c88dbbad08365
    /usr/local/sbin/mycommand