systemd-analyze security 怎样查看沙箱暴露面

我在给 Linux 服务做基础加固时，常会先看一眼 systemd-analyze security。它能把 service unit 的沙箱设置逐项列出来，再给出一个总体 exposure level，适合发现“哪些隔离项还没有启用”。但这个数字的职责很窄：它衡量的是 systemd 自己认识的服务级安全设置，不能直接替代漏洞扫描，也不能证明服务一定安全或一定有漏洞。

官方地址：https://www.freedesktop.org/software/systemd/man/latest/systemd-analyze.html

最实用的读法是：先对指定 unit 看详细项，再把高 exposure 项当成加固线索，最后分别复查服务代码和 IPC 策略。不要只看一个总分下结论。

先区分汇总表和指定 unit 的详细表

这个子命令有两种常见用法。不给 unit 名称时，它会检查当前已加载的长期运行服务，输出较简洁的汇总表；给出一个或多个 service unit 时，才会展开这个 unit 的具体安全与沙箱设置。排障时我更常从指定 unit 开始，因为它能回答“哪一项没有收紧”。

# 先看所有已加载的长期服务，适合找出需要进一步查看的对象
systemd-analyze security --no-pager

# 对指定服务展开详细检查，避免分页器截断记录
systemd-analyze security --no-pager example.service

这里的 example.service 只是占位名，要换成实际 unit。指定 unit 后，输出通常包含检查项名称、当前状态、说明和 exposure 值，末尾还会给出总体 exposure level。命令本身读取的是 systemd 服务配置与相关运行状态，不会替你分析业务代码。

用 security 查看服务的沙箱暴露项

逐项输出比总分更有操作价值。例如 PrivateNetwork=、ProtectSystem=、NoNewPrivileges= 等设置，分别对应网络视图、文件系统写入范围和权限提升限制。某一项前面的叉号，首先说明该项没有按工具期望的方式启用；它不是“已经被攻击”的证据。

# 查看目标 unit 的完整安全设置，并把输出保留在终端记录中
unit_name=example.service
systemd-analyze security --no-pager "$unit_name"

# 同时检查多个服务，便于比较相同部署角色的加固差异
systemd-analyze security --no-pager api.service worker.service

如果输出里的高 exposure 项集中在网络、设备、内核接口或文件系统访问，下一步应该回到 unit 文件确认业务是否真的需要这些能力。不要为了追求一个漂亮数字，直接删掉服务必须使用的权限；加固要和服务的实际职责一起判断。

把 exposure level 当作加固线索

官方手册把总体 exposure level 定义为 0.0 到 10.0 的估计值：数值越高，表示 systemd 看到的沙箱限制越少；数值越低，表示应用了更严格的 systemd 安全限制。这个方向可以帮助排序工作，但不能把它当成跨机器、跨版本都严格可比的风险分数。

我通常按下面的顺序处理：

1. 先记录总分和最突出的单项，而不是只记总分。
2. 查看 unit 的实际业务职责，区分“确实需要”与“历史遗留”。
3. 对可以收紧的设置做小范围修改，再用同一命令复查输出。

需要特别留意组合关系。很多沙箱设置单独启用时并不能完全阻止服务改变环境，systemd 会考虑一部分设置之间的关系，但不会覆盖所有可能的交互。因此，分数变化更适合说明“配置收紧了多少”，不能代替对完整攻击面的判断。

按三层边界复查结果

一张 security 输出至少要分三层读。第一层是工具能观察的 systemd unit 设置；第二层是服务进程自身的代码行为，例如它如何处理输入、加载插件或调用外部程序；第三层是 IPC 访问策略，例如服务能否通过 D-Bus 请求其他服务执行操作。官方文档也明确提醒，完整的安全分析不能只停留在 systemd 的沙箱项。

# 显示 unit 文件及其 drop-in，确认安全设置来自哪里
unit_name=example.service
systemctl cat "$unit_name"

# 只做配置语法与依赖检查；这不是安全评分的替代品
systemd-analyze verify "$unit_name"

配置复查可以解释某个设置为什么出现，但仍然不能推断服务内部行为。比如 unit 限制了文件系统访问，服务仍可能通过被允许的接口完成业务；又比如本地 IPC 被开放时，服务可能请求另一个 unit 代为完成受限操作。复查记录里最好明确写出“systemd 覆盖范围”和“仍待确认范围”。

相关问题

exposure level 越高是不是就代表服务有漏洞？

不是。它只是 systemd 根据服务级沙箱设置计算出的暴露估计值。高值说明可能还有值得收紧的设置，不能单独证明存在可利用漏洞。

为什么同一服务不同机器的总分可能不同？

unit 文件、drop-in、systemd 版本和运行环境都可能不同。比较时应保留详细检查项，不要只比较一个总分。

看完 security 输出后最应该做什么？

先挑出与业务无关的高 exposure 项，回到 unit 配置评估是否能收紧；之后再检查服务自身代码和 IPC 访问策略，形成完整复查结论。

一句话总结：systemd-analyze security 适合回答“这个 unit 的 systemd 沙箱还暴露了哪些面”，不适合独自回答“这个服务是否安全”。把单项检查、总体分数、unit 配置、服务代码和 IPC 策略放在同一张排障记录里，结果才有实际价值。