systemd.exec 怎样限制文件系统访问

我在给长期运行的服务收紧权限时，最容易犯的错是只写一句 ProtectSystem=strict，然后发现程序因为无法写状态目录而启动失败。更稳妥的做法是先列出服务真正需要的文件资产，再用 systemd.exec 把“默认只读、少量写入、无关目录不可见”分别表达出来。

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

ProtectSystem=strict 负责建立只读基线，ReadWritePaths= 只放行明确的写入目录，ProtectHome= 和 InaccessiblePaths= 负责减少可见范围；这些选项依赖文件系统命名空间，不能替代能力和系统调用层面的限制。

下面用一个名为 example-worker.service 的服务说明配置思路。路径只是示例，真正落地前要按程序的配置、状态、缓存和日志需求逐项确认。

先划分服务需要的文件资产

先把服务访问的路径分成四类：程序和系统库通常只需要读取；配置目录可能需要读取；状态和日志目录需要写入；用户家目录、设备节点或其他服务的数据则通常不应被看见。这个清单比直接堆叠安全选项更重要，因为每一个例外都会扩大服务的文件系统视图。

可以先在 unit 中建立只读基线，再显式声明服务自己的状态目录：

[Service]
# 让系统文件、引导目录和默认文件系统视图保持只读
ProtectSystem=strict
# 服务不需要读取用户私有目录时直接隐藏它们
ProtectHome=read-only
# 只允许服务把运行状态写入自己的目录
ReadWritePaths=/var/lib/example-worker /var/log/example-worker

ProtectSystem=strict 会把整个文件系统层级设为只读，但 /dev/、/proc/、/sys/ 等 API 文件系统另有边界；官方文档也建议根据服务需要配合 PrivateDevices=、ProtectKernelTunables= 和 ProtectControlGroups=。ProtectHome=read-only 不是“完全看不见”，而是让 /home/、/root、/run/user 只读；如果服务不应知道这些目录的内容，可以改用 ProtectHome=yes 或 tmpfs。

用 ProtectSystem 和 ProtectHome 收紧默认视图

这两个选项解决的是“默认能看到什么、能不能写”的大范围问题。一个网络服务如果不负责系统更新，通常没有理由修改 /usr、/etc 或整个根文件系统；同理，后台 worker 也不应因为以某个用户运行，就顺手读遍该用户的家目录。

[Service]
# strict 比 full 更强：默认把整个文件系统层级设为只读
ProtectSystem=strict
# 完全隐藏家目录；如果确实需要读取，再改成 read-only 或精确绑定
ProtectHome=yes
# 把设备访问单独收紧，避免仅依赖文件系统只读属性
PrivateDevices=yes

这里的关键是“默认收紧、例外放行”。如果应用需要读一个固定证书目录，不要因此把整个 /etc 恢复为可写；应考虑只读绑定或明确的路径例外。需要注意，ProtectHome 只覆盖标准的家目录层级，非标准位置的 home 目录不自动获得同样保护。

用 ReadWritePaths 放行最小写入目录

服务真正需要写入的通常是状态、缓存和日志，而不是“整个 /var”。ReadWritePaths= 可以在只读基线之上建立写入白名单；它控制的是挂载点在服务命名空间中的可写性，不能把底层超级块本身是只读的文件系统变成可写。

[Service]
# 先把整体文件系统设为只读
ProtectSystem=strict
# 只为状态和日志保留两个写入口，目录名按实际程序调整
ReadWritePaths=/var/lib/example-worker /var/log/example-worker
# 缓存只需要临时存在，使用只读 tmpfs 视图而不是开放整个 /var/cache
TemporaryFileSystem=/var/cache/example-worker:ro

如果程序需要 systemd 自动创建目录，可以研究 StateDirectory=、CacheDirectory= 和 LogsDirectory= 这组目录声明；它们会把目录生命周期和对应环境变量交给 unit 管理，通常比手写许多绝对路径更易维护。写入白名单仍然要以程序实际调用为准，不能因为目录存在就默认放行。

用 InaccessiblePaths 与 TemporaryFileSystem 处理特殊目录

InaccessiblePaths= 适合表达“服务不应访问这里以及下面的内容”，例如完全不需要的备份目录或其他用户数据。它比只读更强，但也更僵硬：被隐藏的路径下面不能再嵌套 ReadOnlyPaths=、ReadWritePaths= 或绑定路径。

[Service]
# 隐藏无关数据；前面的 - 表示路径不存在时不让 unit 失败
InaccessiblePaths=-/srv/backups /home
# 用只读临时文件系统替换缓存根目录，需要的内容再单独绑定
TemporaryFileSystem=/var/cache/example-worker:ro

两者的取舍可以这样记：需要彻底消失的路径用 InaccessiblePaths；需要一个空的、受控的目录视图时用 TemporaryFileSystem，再配合 BindReadOnlyPaths 精确带入必需文件。不要把这两个选项当作“执行顺序”，它们描述的是服务命名空间里的静态可见性和挂载关系。

复查特权、挂载传播和服务类型边界

文件系统限制并不是不可绕过的完整安全边界。官方手册特别提醒，挂载传播可能让后来在主机上创建的子挂载以未修改的方式出现在服务命名空间中；拥有足够特权的进程也可能改变这些映射。因此，服务不应拥有不必要的 CAP_SYS_ADMIN，并可按需求增加系统调用过滤。

[Service]
# 删除服务不需要的挂载管理能力，避免进程重新改变命名空间
CapabilityBoundingSet=~CAP_SYS_ADMIN
# 禁止常见挂载系统调用，具体集合要结合程序能力测试
SystemCallFilter=~@mount
# 防止 execve 通过 setuid、setgid 或文件能力获得新权限
NoNewPrivileges=yes

还要确认 unit 的运行形态。部分依赖文件系统命名空间的设置对 per-user service 不可用，或者需要 PrivateUsers= 和内核用户命名空间支持；容器运行时如果没有提供相应能力，某些限制也可能不生效。复查时应围绕“服务需要读什么、写什么、挂载什么、拥有哪个能力”逐项核对，而不是只看 unit 文件是否能被解析。

我的落地顺序通常是：先用 ProtectSystem=strict 和合适的 ProtectHome 建立基线，再只为状态、日志和确实需要的缓存放行，最后用 InaccessiblePaths 或 TemporaryFileSystem 缩小特殊目录，并补上能力、系统调用和运行形态的复查。这样配置的重点不是“写了多少安全参数”，而是每一条可见路径都能回答它为什么存在。

相关问题

ProtectSystem=strict 后程序写不了状态文件怎么办？

先确认状态文件实际路径，再用 ReadWritePaths 或 StateDirectory 只放行对应目录，不要直接撤销 strict。

InaccessiblePaths 和 ProtectHome=yes 有什么区别？

ProtectHome=yes 是针对标准用户目录的快捷保护；InaccessiblePaths 可以针对任意目录树，但嵌套例外更受限制。

ReadWritePaths 能保证服务绝对不能写其他地方吗？

不能。挂载传播、特权能力和 API 文件系统都会影响边界，应结合 CapabilityBoundingSet、SystemCallFilter 及实际服务需求复查。