Linux 服务只读边界怎么配置：写入白名单与回滚检查

给一个长期运行的 Linux 服务收紧权限时，最容易踩的坑是“一刀切”：把根文件系统设成只读后，应用自己的状态目录也跟着不能写。比较稳的做法是让 systemd 先用 ProtectSystem=strict 收紧系统目录，再用 ReadWritePaths=/var/lib/ward 明确放行唯一的数据目录。这样既能阻止服务误改 /etc、/usr，又不会破坏正常写入。

先把写入范围缩到一个专用目录，再验证服务的成功写入与越界写入分别得到什么结果；不要只看 unit 文件里出现了加固参数。

先划清服务真正需要写什么

假设服务名为 ward.service，程序只需要把运行状态写到 /var/lib/ward，日志交给 journal。这里的保护资产不是“所有文件”，而是系统配置、程序文件和服务自己的状态数据三组不同对象。

这个边界还意味着程序不能把临时文件偷偷写到当前目录或 /tmp 后再声称已经完成隔离。先在测试机上用与生产相同的运行用户创建目录：

sudo install -d -o ward -g ward -m 0750 /var/lib/ward
sudo systemctl cat ward.service

用 ProtectSystem=strict 收紧系统目录

在 /etc/systemd/system/ward.service.d/hardening.conf 写入一个 drop-in。应用本身的启动命令保持不变，加固项只描述文件系统边界：

[Service]
ProtectSystem=strict
ProtectHome=read-only
ReadWritePaths=/var/lib/ward

第一张图把这三个真实节点放在同一条控制链上：systemctl 读取 unit，ProtectSystem=strict 让系统路径只读，ReadWritePaths=/var/lib/ward 再开出应用状态目录。图里的箭头表示配置生效后的权限路径，不代表新增了程序函数。

保存后依次让管理器读取配置并重启服务：

sudo systemctl daemon-reload
sudo systemctl restart ward.service
sudo systemctl --no-pager --full status ward.service

如果服务立刻退出，先看 journalctl -u ward.service -b 的第一条权限错误。不要马上把 ProtectSystem 降回 off，先确认程序是否把配置缓存、临时文件或证书写入了未放行目录。

允许路径与拒绝路径要分开验收

验收至少做三次。ExecStart 是 unit 中真正启动程序的入口，先检查它对应的服务动作能在自己的目录内创建状态文件；第二步确认服务不能改系统文件；第三步重启后确认状态仍然存在。测试文件名使用明显的临时标记，完成后删除。

sudo -u ward sh -c 'printf ready > /var/lib/ward/probe.txt'
sudo -u ward sh -c 'printf blocked > /etc/ward-probe.txt' || echo '拒绝写入符合预期'
test "$(cat /var/lib/ward/probe.txt)" = ready
sudo rm -f /var/lib/ward/probe.txt
sudo systemctl restart ward.service
sudo journalctl -u ward.service -n 30 --no-pager

这里要区分两件事：手工用 sudo -u ward 执行命令，只能说明目录属主和普通权限；服务进程是否真的处于 unit 的文件系统隔离中，要由服务自己的写入动作和 journal 日志共同证明。

三个容易被误判的边界

目录放行不等于程序获得全部权限

ReadWritePaths 只改变指定路径的挂载可写状态，文件属主、传统 Unix 权限和其他 sandbox 设置仍然有效。如果状态目录属于 root，服务用户仍会收到权限拒绝。

ProtectSystem 不等于完整的进程沙箱

它主要限制文件系统写入，不会自动解决网络访问、设备访问、内核能力或凭据暴露问题。需要更强边界时，应按服务实际需要评估 PrivateDevices、RestrictAddressFamilies、能力集等设置，逐项验证。

带 CAP_SYS_ADMIN 的进程要单独评估

官方说明提醒，保留 CAP_SYS_ADMIN 的进程可能削弱这类文件系统保护。因此加固配置上线前要检查服务实际能力，而不是只截图 unit 文件。

回滚与审计记录怎么留

测试失败时保留 drop-in 文件，先执行 sudo systemctl revert ward.service 或移除本次新增的 drop-in，再运行 daemon-reload 和重启。生产环境不要直接删除原 unit；把变更原因、放行目录、失败日志和回滚时间写进变更记录，方便之后判断是路径遗漏还是程序行为变化。

验收记录至少包含：配置文件路径、执行过的 systemctl 命令、允许写入结果、拒绝写入结果、服务重启后的日志摘要。这样下次升级二进制时，可以快速复跑同一组边界检查。

相关问题

为什么服务启动后仍然写不了 /var/lib/ward？

先查目录属主和权限，再确认 drop-in 是否被管理器读取：systemctl cat ward.service 应能看到最终合并结果。

ReadWritePaths 可以放行整个 /var 吗？

技术上可以，但会扩大服务可写范围。更合适的是只放行应用需要的专用子目录，并为目录设置独立属主。

修改 drop-in 后为什么没有生效？

文件变更后要执行 systemctl daemon-reload，再重启服务；只运行 restart 不一定会重新读取管理器配置。

小结

服务加固的关键不是堆更多开关，而是先列出真实写入路径，再用 ProtectSystem=strict 建立默认只读边界，用 ReadWritePaths 开出最小例外，最后用成功、失败、重启后三组结果验收。这个顺序能让权限问题留在测试阶段，也给生产回滚留下清晰抓手。