systemd 服務單元硬化 （★
122 分）
systemd 預設以成功啟動為優先，安全性並非預設考量。為了強化各服務單元（service unit）或 Podman quadlet 的安全性，文章建議先透過 `systemd-analyze security` 分析全系統或指定服務（如 sshd.service）的安全狀態，輸出結果會列出布林檢核、功能名稱、說明，以及風險量化指標（Exposure），以此判斷最亟需優先調整的項目。
要落實硬化設定，可利用 `systemctl edit` 自動產生覆寫配置檔，或手動於 `/etc/systemd/system/ServiceName.service.d/override.conf` 的 `[Service]` 區段新增安全關鍵字。常見選項包括將整體檔案系統設為唯讀（ProtectSystem）、隔離臨時目錄（PrivateTmp）、封鎖家目錄存取（ProtectHome）、限制核心日誌與模組存取（ProtectKernelLogs、ProtectKernelModules）、禁止 setuid/setgid（RestrictSUIDSGID）、禁止新增執行權限之記憶體區段（MemoryDenyWriteExecute）、鎖定執行域（LockPersonality）與限制即時排程（RestrictRealtime）等；更進階的還可細部調整系統呼叫過濾（SystemCallFilter，由 seccomp (安全計算模式) 實作）等。
文章也提供 12 項優先級最高的調校清單，建議初期可依序啟用 ProtectSystem=strict、PrivateTmp=yes、ProtectHome=yes、ProtectClock=yes、ProtectKernelLogs=yes、ProtectKernelModules=yes、RestrictSUIDSGID=yes、UMask=0077、LockPersonality=yes、RestrictRealtime=yes、MemoryDenyWriteExecute=yes 及 DynamicUser=yes（或指定非 root 服務帳號）等，並視服務需求逐步補強。作者並示範在 Traefik quadlet 中整合這些設定，強調應以風險管理與需求為導向，只為對外暴露服務優先進行硬化，而非對所有系統服務一視同仁。
在 Hacker News 討論中，不少人讚賞針對系統呼叫限制的偵錯技巧：可結合 auditd 記錄與 `systemd-analyze` 找到被拒絕的 syscall，再依實際需求於 SystemCallFilter 中放行，還有人提醒可加上 `--user` 參數檢視使用者層級單元。另有開發者分享 systemd 的憑證管理功能（Credential Management），可安全載入密鑰，比環境變數或檔案方式更可靠；也有人推薦以 Madaidan 的 Linux Hardening Guide 作為全系統最佳化參考，並輔以 AppArmor 或 Firejail 等 sandbox 工具強化防禦。
同時，社群就系統管理守護程式（init system）選擇展開熱烈討論：有人認為相較於 SysV Init、OpenRC 與 runit 等以腳本為主的簡易方案，systemd 雖複雜卻提供一致且標準化的介面，能更實用地整合核心功能；也有人抱怨多數套件維護者少有主動提供預設硬化的單元檔，將工作全交由終端使用者。討論中亦不乏對 project 名稱大小寫的玩笑——systemd 正確寫法皆為全小寫。
👥
46 則討論、評論 💬
https://news.ycombinator.com/item?id=44937550