☰

结论

tag-icon • tag-icon security sudo root
结论

我有一个进化先前的问题。

主要问题：以 root 身份运行程序与通过带有 sudoers 文件条目的服务帐户运行程序之间有哪些有意义的区别？

我必须将第三方软件代理部署到我注重安全性的客户的 RHEL 环境中。默认安装会导致代理的文件和文件夹归 root 所有，并且计划在启动或关闭时或通过 crontab 文件运行；但无论哪种方式，它都以 root 进程运行，安全团队中似乎没有人喜欢这样。

供应商建议，更安全的替代方法是通过具有 sudoers 文件条目的服务帐户执行代理：例如：

agent-user ALL=NOPASSWD: /opt/agent/agent-executable

但从安全角度来看，这真的更好吗？或者在这种情况下最佳做法是什么？

在我看来，无论如何，代理都会获得对服务器的特权访问。服务帐户是一种定制，（虽然由供应商支持）似乎是一个犯错的机会。

这是NOPASSWD:一个安全弱点，规定一个外壳是否会/sbin/nologin提高安全性？

答案1

以 root 身份运行程序与通过具有 sudoers 文件条目的服务帐户运行程序之间有什么有意义的区别？
但从安全角度来看，这真的更好吗？或者在这种情况下最佳做法是什么？

结论

最终结果确实是一样的：/opt/agent/agent-executable以 root 权限运行，并承担与该权限级别相关的所有风险。

“最佳实践通常只是另一种观点。”

我认为，当服务由主进程和（许多）不需要 root 权限即可正常运行的组件组成且使用身份时可以顺利运行，我建议使用 sudo 选项agent-user，但有些特定的、容易识别的组件（如agent-executable）确实需要此类 root 访问权限。
这需要管理员授予权限，并且主服务支持在修改后的上下文中以提升的权限运行这些特定组件的能力。 sudo特别适合这种情况（并且比在可执行文件上设置 SUID 位等要好得多）。

然后你坚持安全最小特权原则。

例如，当你创建一个这样的 systemd 单元时：

[Service]
User=agent-user
ExecStart=sudo /opt/agent/agent-executable

它指示 systemd（以 root 身份运行）切换到 agent-user 身份，以在权限较低的环境中运行服务。然后，作为该受限用户，您可以使用sudo再次提升权限以 root 身份运行服务。
在这种情况下，您只是在犯傻，不妨从一开始就以 root 身份启动 agent-executable 并执行以下操作：

[Service]
# User=root
ExecStart=/opt/agent/agent-executable

笔记：当你通过 sudo 或 systemd 启动进程时，产生的环境会有一些细微的差别（带或不带明确的User=root) 目前可能还不相关。

NOPASSWD 是否存在安全漏洞？

在服务和自动化的情况下常常不可避免地会出现这种情况。

规定 /sbin/nologin 的 shell 是否会提高安全性？

总体而言：远没有人们想象的那么多。例如参见此问答。

相关内容