我有一個早期問題的演變。

主要問題：以 root 身份執行程序與通過具有 sudoers 文件條目的服務帳戶執行程序之間有什麼有意義的區別？

我必須將第 3 方軟體代理部署到具有安全意識的客戶的 RHEL 環境中。預設安裝導致代理的文件和文件夾歸 root 所有，併計劃在啟動、關閉或通過 crontab 文件執行；但無論哪種方式，它都作為根程序執行，安全團隊中似乎沒有人喜歡。

供應商建議更安全的替代方法是通過具有 sudoers 文件條目的服務帳戶執行代理：例如：

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

但從安全的角度來看，這實際上更好嗎？或者在這種情況下最佳做法是什麼？

在我看來，無論哪種方式，代理都將獲得對伺服器的特權訪問。服務帳戶是一種自定義（雖然由供應商支持）似乎是一個犯錯的機會。

是NOPASSWD:一個安全漏洞，並且會規定一個/sbin/nologin提高安全性的外殼？

以 root 身份執行程序與通過具有 sudoers 文件條目的服務帳戶執行程序之間有什麼有意義的區別？

但從安全的角度來看，這實際上更好嗎？或者在這種情況下最佳做法是什麼？

TLDR

最終結果確實是一樣的：/opt/agent/agent-executable以 root 權限執行，所有風險都與該權限級別相關。

“最佳實踐往往只是另一種意見。”

---

恕我直言，當服務由主程序和（許多）組件組成時，我建議使用 sudo 選項，這些組件不需要 root 權限才能正常執行，並且在使用agent-user身份時會愉快地執行，但是有一些特定的，很容易已辨識的組件（如agent-executable）確實需要這樣的 root 訪問權限。

這需要管理員和主要服務支持在修改後的上下文中以提升的權限執行這些特定組件的能力。 sudo特別適合這種情況（並且是比在執行檔上設置 SUID 位更好的選擇）。

然後你堅持最小權限的安全原則。

例如，當您創建這樣的 systemd 單元時：

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

它指示 systemd（以 root 身份執行）切換到代理使用者的身份，以在特權降低的環境中執行服務。然後，作為受限制的使用者，您可以sudo再次提升權限以以 root 身份執行服務。

在那種情況下，您只是很傻，不妨從一開始就以 root 身份啟動代理執行檔並執行以下操作：

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

注意：當您通過 sudo 或 systemd（帶有和不帶有顯式User=root）啟動程序時，生成的環境存在一些細微的差異，這些差異在此時可能不相關。

NOPASSWD：是安全漏洞嗎？

在服務和自動化的情況下通常是不可避免的。

規定 /sbin/nologin 的外殼會提高安全性嗎？

總的來說：沒有人們想像的那麼多。例如，請參閱此 Q&A。

引用自：https://serverfault.com/questions/963100