用systemd硬化一个备份服务：5项配置，和4个必然踩到的坑

先看一行输出。在一台刚装好的 Ubuntu 24.04 上，给自写的备份脚本配好 systemd 服务，运行 systemd-analyze security，它给出 9.6，评级 UNSAFE。9.6 的意思是「几乎不做任何限制」，分数越低越安全。

大多数自建服务都停在这个位置，不是因为不管，是因为默认值就是这么松。下面这份配置把它压到 2 附近，用到的全部是 systemd 自带的开关，不需要容器，不需要改代码。硬化要解决的不是「会不会被打」，是「被打中之后能走多远」。

本文环境：Ubuntu 24.04 LTS，systemd 255，源目录 /srv/data，落地目录 /srv/backup，服务名 bk.service，运行用户 backup。下面每一步都对应一个具体的开关，可以只挑其中几项用。

/srv/
├── data/                  # 只读源
│   ├── app/
│   └── uploads/
├── backup/                # 可写目标
│   └── 2026-11/
/etc/systemd/system/
└── bk.service
/usr/local/bin/
└── backup.sh

1. 把根文件系统设成只读

ProtectSystem=strict 会把整个文件系统挂成只读，包括 /usr、/etc、/boot，连 /var 也一起。写完这一行，服务立刻起不来——因为它连日志都写不进去。这不是配置失误，是硬化本身的性质：先全部关掉，再一个一个开回来。

开回来的方式有三种，按精细程度递增：ReadWritePaths 给具体路径，LogsDirectory 和 StateDirectory 让 systemd 建目录并授权。后者比在脚本里 mkdir 再 chown 可靠，因为目录在服务启动之前就已经存在，属主也由 systemd 维护。启动顺序上的确定性，比权限本身更值钱。

ProtectSystem=strict
ReadWritePaths=/srv/backup
LogsDirectory=backup
StateDirectory=backup

2. 私有临时目录

PrivateTmp=yes 给服务一个独立的 /tmp 和 /var/tmp，其他进程看不见，服务自己也看不见别人的。这一项几乎没有副作用，唯一要注意的是互斥锁：如果你在脚本里写死了 /tmp/backup.lock 去做单实例，硬化之后这个锁只对本服务有效，手工跑的同一脚本看不到它。互斥要用 flock 加在真实路径上，不要指望 /tmp 里的文件当锁。

3. 关掉家目录

ProtectHome=yes 让 /home、/root、/run/user 对服务不可见。备份脚本经常顺手读 ~/.ssh 里的密钥去做远端同步，这一行会让它当场失败。失败是好事，因为它暴露了一个事实：密钥一直放在只有人能读的地方。

正确做法是把密钥移到 /etc/bk/id_ed25519，属主 root、权限 600，再用 ReadOnlyPaths 挂进去。密钥跟着服务走，不跟着人走，这本身就是一次权限收敛。顺带的好处是：人离职时不用再想起来删一遍密钥。

4. 只留需要的协议族

RestrictAddressFamilies 限制服务能创建哪些 socket，备份只连远端 SSH 的话，AF_INET 和 AF_INET6 就够。但漏掉 AF_UNIX 会出一个很难查的错：某些库在初始化时会去连 /run/dbus/system_bus_socket，拿不到就打印一行含糊的 warning 然后继续。你只会觉得「怎么慢了两秒」，不会想到是权限问题。

RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX

5. 收掉能力位与系统调用

NoNewPrivileges=yes 禁止服务通过 setuid 提权，CapabilityBoundingSet 留空表示一个 capability 都不给，SystemCallFilter=@system-service 只放行常规服务需要的系统调用。这三项一起上，服务的「可行动空间」会缩得很小。缩小之后仍然跑得起来，才算证明了它本来就不需要那么多。

SystemCallErrorNumber=EPERM 让被拦下的调用返回「权限不足」而不是直接杀掉进程，这样脚本还能打出有意义的日志。直接 SIGSYS 会让人以为是段错误，排查时间能翻三倍。

完整的一份 unit

[Unit]
Description=Nightly backup of /srv/data
After=local-fs.target

[Service]
Type=oneshot
User=backup
Group=backup
ExecStart=/usr/local/bin/backup.sh

ProtectSystem=strict
ReadWritePaths=/srv/backup
LogsDirectory=backup
StateDirectory=backup

PrivateTmp=yes
ProtectHome=yes
PrivateDevices=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
ProtectClock=yes
ProtectHostname=yes

RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
RestrictNamespaces=yes
RestrictRealtime=yes
LockPersonality=yes

NoNewPrivileges=yes
CapabilityBoundingSet=
AmbientCapabilities=
SystemCallFilter=@system-service
SystemCallErrorNumber=EPERM
MemoryDenyWriteExecute=no

[Install]
WantedBy=multi-user.target

MemoryDenyWriteExecute 单独留成 no，原因在最后一节。其余全部打开，这是一份可以直接用的起点，不是示意。照抄它至少能让你少走一遍「改一项、重启、看日志」的循环。

验收：一个分数，三条实测

改完 unit 先 daemon-reload，再逐条实测。分数只是参考，行为才是证据。评分表会因为你关掉一个用不到的开关而加分，但只有实测能证明它没把需要的也关掉。分数从 9.6 降到 2 附近，靠的主要是那十来个布尔开关，剩下的都是细节分。

别把 2 当成目标。分数到 2 之后继续压，通常要开始动 SystemCallFilter 的白名单，收益很小，而每一次内核升级都可能让它失效。把分数当成体检指标，而不是考试成绩。

systemctl daemon-reload
systemctl restart bk.service
systemd-analyze security bk.service
systemctl show bk.service -p ProtectSystem -p PrivateTmp -p NoNewPrivileges

第一条实测：在服务里故意写 /etc/bk-test，应该报 Read-only file system。第二条：读 /root/.ssh/id_rsa，应该报 No such file。第三条：往 /var/log/backup 写一个文件，应该成功。三条都符合预期，才说明「关掉的真关掉了，放开的是真放开」。

硬化最容易出的事故不是太严，是严了但没验证，等到下一次真备份时才发现写不进去。这类事故通常在凌晨三点被发现，而且第一次发现时看起来像磁盘满了。所以验收要在白天做，并且三条都要做。