Linux 服务如何用只读基线限制写入范围：ReadWritePaths 权限边界

一个写入本地账本的 Linux 服务，真正需要的通常只是 /var/lib/ledger，却常被配置成整个根文件系统可写。把 unit 收紧到 ProtectSystem=strict 后，再用 ReadWritePaths=/var/lib/ledger 精确放行，服务仍能保存业务数据，误写系统目录的路径则会在服务自己的命名空间里失败。

先把服务写入目标缩到一个专用目录，再验证目录所有者、unit 生效状态和失败日志；不要为了让服务启动而直接撤掉 ProtectSystem。

先确定服务到底要写什么

假设服务名为 ledger-writer.service，程序只把账本文件放到 /var/lib/ledger。日志由标准输出交给 journald，不在程序里自行创建系统日志文件。这个边界很重要：如果一开始把“保存业务数据”和“写日志”混成一个可写目录，后面的权限审计会很难判断。

[Service]
ExecStart=/usr/local/bin/ledger-writer
StateDirectory=ledger
ProtectSystem=strict
ReadWritePaths=/var/lib/ledger

这里的几个稳定标识符是后面核对的依据：ProtectSystem=strict 提供只读基线，ReadWritePaths 给出例外，/var/lib/ledger 是唯一业务写入点。

用 ProtectSystem=strict 建立只读基线

把配置放在 /etc/systemd/system/ledger-writer.service.d/sandbox.conf，避免直接修改发行版提供的 unit。写入后执行：

sudo systemctl daemon-reload
sudo systemctl restart ledger-writer.service
systemctl show ledger-writer.service -p ProtectSystem -p ReadWritePaths

输出中应能看到 ProtectSystem=strict 和包含 /var/lib/ledger 的 ReadWritePaths。如果只看到了 unit 文件，却没有重新加载 manager，运行中的服务仍可能使用旧配置。

只放行 ReadWritePaths 指定的目录

ReadWritePaths 是路径白名单，不是“给进程加一个目录权限”的替代品。目录本身仍要满足 Unix 所有者和模式要求。先创建目录并把所有权交给服务用户：

sudo install -d -o ledger -g ledger -m 0750 /var/lib/ledger
sudo -u ledger sh -c 'touch /var/lib/ledger/check.tmp'
sudo rm /var/lib/ledger/check.tmp
findmnt -T /var/lib/ledger -o TARGET,OPTIONS

成功标准是服务用户能在 /var/lib/ledger 创建临时文件，findmnt 能确认该路径在当前服务视角可写。若出现 Permission denied，先查目录所有者和 ACL；不要先把 ProtectSystem 改回 no。

用失败证据确认权限边界

加固不是只看服务能否启动，还要确认它不能写入不该写的区域。可以让测试模式尝试创建 /usr/local/share/ledger-probe，再立即查看 journal：

sudo systemctl reset-failed ledger-writer.service
sudo systemctl start ledger-writer.service
sudo journalctl -u ledger-writer.service -n 30 --no-pager
systemd-analyze security ledger-writer.service

业务目录写入成功而系统目录写入失败，才说明边界成立。systemd-analyze security 的分数只能作为检查线索，不能替代对真实写入路径的验收。

发布前的回滚与复查

上线前保留 drop-in 文件的版本记录；回滚时只移除这次新增的 sandbox 配置，再执行 daemon-reload 和重启。若服务依赖其他运行时目录，逐个加入最小路径并重复验证，不要把根目录或整个 /var 一次性放开。

• 配置核对：systemctl cat ledger-writer.service 是否只包含必要例外。
• 路径核对：findmnt -T /var/lib/ledger 与服务实际写入位置一致。
• 日志核对：journalctl -u ledger-writer.service 能看到启动和失败原因。
• 回滚核对：移除 drop-in 后，unit 能恢复到变更前的明确状态。

常见问题

ProtectSystem=strict 会不会让服务完全不能写文件？

不会。它先建立只读基线，再由 ReadWritePaths 指定例外；前提是目录的 Unix 权限也允许服务用户写入。

为什么 ReadWritePaths 写了目录仍然 Permission denied？

先检查目录所有者、ACL、父目录搜索权限和程序实际路径。路径白名单不能替代普通文件权限。

日志目录要不要加入 ReadWritePaths？

如果程序写标准输出，通常不需要；让 journald 接管日志更容易审计。只有确认程序必须写专用日志目录时，才单独放行该目录。

总结

这套配置的核心不是记住一个 hardening 参数，而是把“服务能写哪里”变成可核对的清单：ProtectSystem=strict 负责默认拒绝，ReadWritePaths 负责最小放行，目录权限和 journal 证据负责证明配置确实生效。