Linux 服务单元怎么加固：只读根、私有临时与可写路径白名单

一台API服务用专用账号运行，日志和数据也放在单独分配的位置，看起来已经不算高权限。但它一旦被漏洞利用，进程仍可能读取非授权用户文件、把临时文件留在共享位置，甚至改写本不该触碰的宿主机存储路径。服务单元还能再加一层边界：根路径设为只读、临时位置完全隔离、只放行必要的写入位置白名单。

普通的低权限运行账号没法彻底把服务和宿主机其他路径隔离开。用服务单元的沙箱能力划定只读边界、隔离临时位置、用白名单锁死允许写入的路径，能以较低成本缩小漏洞利用后的影响范围。

先把服务要保护的资产说清楚

需要保护的不是抽象的服务器安全，而是几类具体资产：/etc 下的配置和密钥、其他服务的数据位置、共享的临时文件、应用自己的上传位置和运行日志。服务进程只应拥有完成业务所需的最小文件视图。

常见风险路径并不复杂：应用接收了畸形文件名，第三方组件默认写入公共临时位置，或者调试代码把运行用户可见的配置明文打进日志。专用账号能缩小权限范围，但不等于把文件访问面切成互相隔离的独立分区。目标是让越界访问直接触发权限拒绝，第一时间中断非法操作。

最小可用的单元加固片段

不要直接修改发行版或部署工具生成的主单元文件。通过服务管理工具建立drop-in追加配置，后续升级包或重新部署时更不容易丢失自定义规则。下面的配置示例默认服务只需要写业务数据、日志与运行时状态。

[Service]
NoNewPrivileges=yes
PrivateTmp=yes
ProtectHome=yes
ReadWritePaths=/var/lib/inventory /var/log/inventory /run/inventory

根路径只读策略的收紧力度很高，服务进程看到的绝大多数路径都会变成只读状态；ReadWritePaths 因此必须列出所有真正需要写入的位置。上传位置如果在 /srv/inventory/uploads，就加入这个精确路径，完全没必要放开整个 /srv 公开路径。

不同发行版支持的指令会有差异，服务也可能依赖证书刷新、socket文件或外部挂载点。先别急着把更多路径塞进白名单，权限拒绝日志反馈的真实需求，比提前预判放开所有路径要靠谱得多。

部署前把写入需求做成清单

先把服务真实写入的位置逐一列出来：数据库文件、上传位置、应用日志、PID文件或socket文件、运行时缓存。通过发行版提供的服务管理命令读取当前单元配置，再重载配置、重启目标服务并查看最近日志；这些操作不会修改业务数据，适合放到灰度验证清单中。

检查单元当前配置
重载单元配置
重启目标服务
查看服务状态与最近日志

灰度机器上至少跑三类请求：普通读接口、会写入业务数据的接口、涉及临时文件处理的逻辑。如果出现 Permission denied 报错，先核对被拒绝的具体路径，再判断它是否真的属于服务的职责范围。把所有未知路径直接加入白名单，只会让隔离边界越来越模糊，最后回到几乎没有防护的状态。

先观察拒绝，再决定是否扩大白名单

加固后的正常状态不是日志里一个错误都没有，而是服务核心链路全正常、非必要路径完全不可写、运维能解释清楚每一条白名单的作用。对于日志轮转或证书更新这类外部任务，优先把职责拆分给专门的运维任务处理，不要随便把关联路径加到业务服务的可写名单里。

如果健康检查不通过，回退操作也很简单：从drop-in配置里移除刚加的异常规则或者临时注释掉对应项，再重载配置并重启服务即可。先保留当时的日志证据，后续在测试环境重放相同请求，才能定位问题到底是指令兼容性不足、路径遗漏，还是应用本身存在越界写入的逻辑。

相关问题

根路径只读策略会不会让服务完全不能写文件？

它会大幅收紧默认的可写范围，所以需要用ReadWritePaths显式放行服务职责内的精确路径，提前盘点清楚所有实际写入的位置再启用就不会出问题。

PrivateTmp能替代应用自身的临时文件清理吗？

不能。它只解决不同服务之间临时位置互相隔离的问题，不负责临时文件的生命周期管理。过期清理、容量上限和异常文件处理仍需要单独实现。

为什么不直接用root跑服务？

root账号会大幅扩大错误和漏洞的影响范围。遇到权限拒绝的报错，应该先判断服务是不是真的需要该路径，而不是直接用更高权限绕过安全边界。

如何判断某条白名单是否设置过宽？

看它是不是覆盖了服务完全用不到的子路径。优先使用精准的业务位置，如果某个位置没法归类为数据、日志或者运行时状态，就应该继续拆分细化。

收尾：可写路径越少，排查范围越小

服务单元加固不是一次性贴完所有安全开关的操作。先梳理清楚服务要保护的资产和实际写入面，再用少量隔离指令划定边界，最后通过灰度请求和日志回溯修正白名单，就能让服务正常跑业务的同时，不会把宿主机的所有存储路径都暴露在风险里。