Linux 服务隔离如何检查：用安全评估命令查看暴露面并验收加固字段

给 Linux 服务做 systemd 加固时，最容易误判的是“配置写上了”就等于“隔离生效”。更稳妥的做法是先运行 systemd-analyze security your.service，把它给出的暴露面估计当作检查入口，再逐项确认服务是否真的能在更窄的文件系统和权限边界里工作。

先把 systemd-analyze security 的分数读对

在一台使用 systemd 的 Linux 主机上，先选一个不承担关键写入的测试服务，例如 demo-worker.service，执行：

sudo systemd-analyze security demo-worker.service

输出会列出多项安全相关设置，并给出一个 0.0 到 10.0 的暴露面估计。数值越低通常代表限制更强，但它只覆盖 systemd 提供的服务级安全机制；程序本身的漏洞、依赖包风险和业务鉴权并不会因为分数下降而消失。

这里先别急着追一个“漂亮分数”。先记下当前服务的写入目录、临时文件需求和是否需要切换用户，再从能解释清楚的字段开始改。这样出现启动失败时，回滚点也明确。

把检查结果变成可复查的证据

可以把结果保存到变更记录中，重点关注标记为不安全或未启用的条目：

sudo systemd-analyze security demo-worker.service | tee /tmp/demo-worker.security.txt
sudo systemctl status demo-worker.service --no-pager

systemctl status 显示服务仍为 active (running)，只能证明它当前活着；它不能单独证明文件系统隔离正确。因此后面每个字段都要配一个与服务职责相关的验收动作。

用三个字段收紧服务边界

先用 drop-in 覆盖，而不是直接改发行版提供的 unit 文件：

sudo systemctl edit demo-worker.service

写入下面这组偏保守的起点：

[Service]
ProtectSystem=strict
PrivateTmp=yes
NoNewPrivileges=yes

ProtectSystem=strict 让服务看到的系统目录默认只读；PrivateTmp=yes 为服务提供独立的临时目录视图；NoNewPrivileges=yes 让进程及其子进程不能再通过执行文件获得新的特权。三个设置解决的是不同边界，不能把其中一个当成另外两个的替代品。

服务需要写目录时，用 ReadWritePaths 精确放行

如果 demo-worker.service 必须写入 /var/lib/demo-worker，不要因为启动报错就撤掉 ProtectSystem=strict。在同一个 drop-in 中增加：

[Service]
ReadWritePaths=/var/lib/demo-worker

这表示只为明确的业务数据目录开放写入范围。目录不存在、权限归属错误或程序还在写其他路径时，服务仍可能启动失败；应根据日志补齐真实需求，而不是用一个过宽的根目录放行。

重载、重启，再做一次验收

保存 drop-in 后按固定顺序执行：

sudo systemctl daemon-reload
sudo systemctl restart demo-worker.service
sudo systemctl status demo-worker.service --no-pager
sudo systemd-analyze security demo-worker.service

可见成功状态包括：服务状态仍是 active (running)，日志没有因只读文件系统或临时目录失败而循环重启，业务数据能写入 /var/lib/demo-worker，而系统目录写入会被限制。若启动失败，先看：

sudo journalctl -u demo-worker.service -b --no-pager -n 80

确认失败路径后，只增加一个最小的 ReadWritePaths 或修正目录权限，再重载和重启。每次只改一个边界，才能知道哪个字段产生了影响。

常见问题

systemd-analyze security 分数低就代表服务安全了吗？

不是。它主要估计 systemd 服务级沙箱暴露面，不能替代代码审计、依赖更新、网络访问控制和业务权限检查。

ProtectSystem=strict 会不会让所有服务都无法运行？

不一定。只读约束是否冲突取决于服务真实写入路径。对确需写入的目录，应使用 ReadWritePaths 做窄范围放行并检查目录权限。

修改 unit 文件后为什么配置没有变化？

drop-in 保存后需要执行 systemctl daemon-reload，服务本身还需要重启才能让新的进程获得这些设置。

把评分当作起点，而不是结论

一轮合格的 systemd 加固至少留下三类证据：修改前后的安全检查结果、服务重启后的运行状态，以及关键业务目录和受保护目录的读写验证。这样即使分数没有明显下降，也能判断限制是否贴合服务职责；如果业务行为变了，也能从 drop-in 里快速回退单个字段。