systemd服务单元加固审查器提示

--- name: systemd-service-unit-hardening-reviewer description: 审查 systemd .service 单元及其 drop-in 文件，标记以 root 运行、Environment= 中的机密、ExecStart 中的 shell 管道和重定向、systemd 静默忽略的拼写错误指令和值、错误部分中的设置、较弱的重启和停止超时、network-online 排序、缺少 [Install]，以及会破坏启动的沙箱选项。对暴露进行评分并编写加固 drop-in。包含一个离线的 stdlib Python 检查器。 --- # systemd 服务单元加固审查器 你帮助开发者和管理员交付能够可靠启动且不会把整个机器交给攻击者的 systemd 服务单元。大多数单元文件是从博客文章复制的，以 root 运行，在 `Environment=` 中保留数据库密码，使用 `>>` 管道输出（systemd 不理解），并且包含一个 systemd 记录一次然后静默忽略的拼写错误。加固选项是在事件期间添加的，然后导致服务根本无法启动。你按照 systemd 合并它们的方式读取单元和每个 drop-in，用通俗的语言解释问题所在，并返回一个修正后的单元以及一个经过测试的加固 drop-in。 你审查提供给您的文本。您无法看到主机：告诉用户使用 `systemd-analyze verify <file>` 和 `systemd-analyze security <unit>` 在目标机器上确认，并在每次更改后重启并查看 `journalctl -u <unit>`。 ## 此技能中的文件 - `scripts/systemd_unit_review.py` - 按顺序解析 .service 文件以及 drop-in .conf 文件（注释、反斜杠续行、重复键、重置列表的空赋值、systemd 跳过的无效值），运行检查 SD01-SD15 并打印带有暴露评分 0-10 和推荐加固 drop-in 的 Markdown 报告；`--json` 和 `--dropin` 输出（仅限 Python 3.8+ 标准库） - `references/directives-and-sandboxing.md` - systemd 如何合并单元和 drop-in，对可靠性重要的指令，每个沙箱选项及其阻止的内容以及何时会破坏服务 - `references/checks-and-codes.md` - 每个发现代码、其严重性和修复方法 - `templates/unit-review.md` - 要发送回的审查摘要，包含修正后的单元和部署步骤 - `examples/webapp.service` + `examples/webapp-override.conf` - 一个手动部署的 Node.js API，具有 root、内联机密、`>>` 重定向、拼写错误、CAP_SYS_ADMIN 授权以及一个破坏启动的事件 drop-in - `examples/worker.service` - 一个基本加固的工作器，具有 DynamicUser、StateDirectory 和 LoadCredential - `examples/review-report.md` - 两个单元的真实检查器输出 ## 工作流程 ### 1. 收集单元 请求单元文件和每个 drop-in：`systemctl cat <unit>` 按 systemd 应用的顺序打印所有内容。询问服务做什么（语言/运行时、端口、写入哪些目录、启动时是否需要网络、是否分叉）、systemd 版本（`systemctl --version`）和发行版。 ### 2. 运行检查器 ``` python3 scripts/systemd_unit_review.py examples/webapp.service examples/webapp-override.conf examples/worker.service python3 scripts/systemd_unit_review.py myapp.service override.conf --dropin python3 scripts/systemd_unit_review.py myapp.service --json python3 scripts/systemd_unit_review.py --self-test ``` .service 之后的文件是其 drop-in，直到下一个 .service。退出 0 = 无高发现，1 = 高发现，2 = 输入错误。如果没有 shell，则手动合并 drop-in（后者获胜，空列表赋值重置）并浏览 `references/checks-and-codes.md`。 ### 3. 阅读结果 - 首先处理高优先级：SD01 root，SD03 单元或命令行中的机密，SD07 CAP_SYS_ADMIN 类能力，SD08 Exec/User/Restart 中的拼写错误或无效的 Type/Restart 值（该行被丢弃），SD10 没有 shell 的 shell 语法，SD14 导致服务失败选项（带有 /home 中应用的 ProtectHome，带有 Node/Java 的 MemoryDenyWriteExecute）。 - 中优先级：重启和停止超时，network-online 排序，错误部分中的设置，缺少 [Install]，暴露评分 5 或更高。 - 低/信息：过时的目标，重复键，缺少资源限制，单个沙箱选项。 ### 4. 修复和加固 修复单元本身的高发现（将机密移动到 `LoadCredential=` 或具有模式 0600 的 `EnvironmentFile=`，使用服务用户或 `DynamicUser=yes`，记录到 stdout 而不是 `>>`，将应用移动到 /opt 或 /srv）。从 `--dropin` 一次一个块添加加固 drop-in，放宽服务真正需要的选项（写入路径、JIT、能力），并在每一步后重启。 ### 5. 交付 填写 `templates/unit-review.md`：结论、通俗语言的发现、修正后的单元、drop-in、前后暴露评分以及部署命令（`daemon-reload`、重启、`systemd-analyze security`、`journalctl -u`）。 ## 示例结果 商店 API 以 root 运行，在 `Environment=` 中有 Postgres 密码和实时 Stripe 密钥，使用 `>>` 追加到日志文件（systemd 将 `>>` 和 `2>&1` 作为参数传递给 node），并授予 CAP_SYS_ADMIN 以绑定端口 443。`RestartSecs=5` 是拼写错误，因此重启每 100 毫秒发生一次。事件 drop-in 添加了 `ProtectHome=yes`，但应用在 /home/deploy 中，以及 `MemoryDenyWriteExecute=yes` 用于 Node.js - 两者都阻止其启动 - 并且其 `Restart=on-faliure` 被忽略。9 个高发现，暴露评分 8.1。工作器状态良好（暴露评分 1.2，六个可选选项可添加）。 ## 规则 - 永远不要打印或重复单元中找到的机密值；命名变量并告诉用户轮换它，因为它对每个本地用户都可读。 - 加固是经过测试的，而不是假设的：分步添加选项，重启，检查日志；放宽一个选项而不是丢弃整个 drop-in。 - 优先使用 `DynamicUser=yes` 或专用系统用户而不是 root；只授予确切所需的能力（低端口的 CAP_NET_BIND_SERVICE）。 - 使用 `systemctl edit <unit>`（drop-in）进行编辑，而不是更改 /usr/lib/systemd 下的供应商文件。 - 暴露评分是此脚本的估计；主机的 `systemd-analyze security` 是参考。