Systemd安全沙箱实战：用最小权限锁死你的服务

这条报错我先放这儿：wsl: failed to start the systemd user session for 'root'. see journalctl for details。很多人看到它第一反应是"坏了，systemd又出问题了"，然后跑去看日志，折腾半天发现其实是用户会话没起来。Systemd就是这样，表面上是"开机启动服务"的进程管理器，实际越往下挖越发现它是一整套操作系统管理框架。尤其是到了沙箱化和安全加固这一层，很多人根本没意识到，自己天天用的systemd其实自带了一整套安全机制，可以用最简单的方式把一个服务锁死。

这篇是Systemd系列的第五篇，前面几篇如果都跟下来了，你现在应该能用unit文件写服务、用timer替代cron、用journalctl查日志、用socket activation管理依赖。这一篇我们换个视角——不讲怎么让服务跑起来，讲怎么让服务跑起来之后不被人搞。主题是Systemd的安全沙箱机制和最佳实践，核心内容包括：文件系统隔离、权限限制、能力裁剪、系统调用过滤，以及一条命令给服务安全打分的systemd-analyze security工具。

如果你维护过任何暴露在公网的服务，或者你在公司里负责中间件部署，这篇文章值得看完。哪怕你只是在自己服务器上跑了几个Docker容器和自写脚本，这套东西也能帮你把攻击面压缩到一个很小的范围。

1. 为什么Systemd是安全加固的隐藏利器

1.1 从威胁模型说起：服务被攻破之后会发生什么

先说一个容易被忽略的事实：我们做安全加固，重点不是防止服务被攻破，而是假设服务已经被攻破之后，怎么让攻击者什么都干不了。

举个例子。你在一台服务器上跑了一个Nginx，nginx.conf里写错了某个配置，或者PHP代码里存在一个文件包含漏洞，攻击者拿到了Web服务的执行权限。这时候他会做什么？大概率是这几件事：读/etc/shadow提取密码哈希、扫描内网、下载工具、尝试提权、甚至直接删库跑路。

如果你只是裸跑一个nginx.service，那这些操作几乎是畅通无阻的。因为默认情况下，systemd启动的进程继承的是完整的权限集合，能读写哪些文件、能调用哪些系统调用、能访问哪些内核接口，完全没有限制。

但如果你给这个服务配置了ProtectSystem=strict、PrivateTmp=true、NoNewPrivileges=true，情况就完全不一样了。攻击者拿到的那个shell，会发现自己连/etc目录都写不进去，/tmp也不是原来的/tmp，想执行/usr/bin/curl下载工具，结果系统调用被拦了。这就是沙箱化的价值——它不是让你的服务更强大，而是让你的服务被攻破之后，攻击者寸步难行。

这里有一个经常被误解的点：Systemd的沙箱不是虚拟机，也不是容器。它没有独立的网络栈，没有独立的PID命名空间（除非你开PrivatePids），它做的事情本质上是"限制"，而不是"隔离"。同一个内核，同一套文件系统，但通过权限裁剪、命名空间隔离、系统调用过滤等手段，把进程能碰到的东西限制在最小范围内。这种思路和Docker的--security-opt、Kubernetes的SecurityContext是同源的——大家都走的是Linux内核那一套机制，只是Systemd把这些机制包装成了unit文件里一行行的配置。

1.2 Systemd沙箱的能力范围

Systemd的沙箱参数主要定义在systemd.exec手册里，服务进程在execve之前，systemd会按顺序完成一系列准备工作：创建新的挂载命名空间、设置文件系统保护、裁剪capabilities、应用系统调用过滤器。这些能力大致可以分成四层：

这四层可以叠加使用，配合systemd-analyze security给出的安全等级评估，你能很直观地看到每个配置项对整体安全的影响。

2. 安全沙箱核心参数拆解：原理与实战

2.1 文件系统隔离：ProtectSystem与PrivateTmp

文件系统隔离是沙箱里最常用、效果最明显的一类参数。

ProtectSystem有三个级别。默认是no，不做任何限制。ProtectSystem=yes表示/usr、/boot、/etc变成只读。ProtectSystem=full在前面基础上再加上/efi和/etc。ProtectSystem=strict则是整个文件系统除了/dev、/proc、/sys这几个虚拟文件系统之外全部变成只读。

实际使用中，绝大部分服务根本不需要写/usr和/etc，所以ProtectSystem=strict是代价最低收益最高的配置之一。但有个问题要注意：如果你某个服务确实需要写/etc下的某个配置文件，strict模式会直接让这个写入失败，而且报错通常是权限问题，排查起来容易懵。这时候你需要用ReadWritePaths=把特定路径重新放回可写状态。

再来看PrivateTmp=true。这个参数很妙，它会给服务进程创建一个私有的/tmp和/var/tmp挂载命名空间。什么意思呢？就是服务进程看到的/tmp和宿主机上的/tmp不是同一个。攻击者就算在/tmp下放了恶意文件，别的进程也看不到——反之亦然，别人也看不到服务自己的临时文件。这个功能用的就是Linux的namespace机制，和容器是同一套底层技术。

我自己的习惯是：除了极少数需要跨进程共享临时文件的服务，一律开PrivateTmp=true。有个坑是，如果你用/tmp来传递Unix socket，开了PrivateTmp之后别的进程可能连不上。这时候优先考虑换/run目录，因为/run本身就是设计用来放运行时文件的。

ProtectHome=true则更直接：把/home、/root、/run/user整个锁掉，进程完全不可访问。对绝大多数服务来说，它完全没有任何理由去读用户的家目录。如果嫌这个还不够狠，ProtectHome=read-only是只读版本，ProtectHome=tmpfs则是给这三个目录挂一个空的tmpfs，进程能访问但内容不存在。

2.2 内核接口保护：ProtectKernelTunables与相关参数

内核接口是很多人会忽略的重灾区。

/proc/sys和/sys这两个目录看起来只是普通文件，实际上它们映射的是内核的运行时参数。一个进程如果能写/proc/sys/kernel/hostname，就能改主机名；如果能写/proc/sys/kernel/core_pattern，那基本上等于拿到了root权限的钥匙（通过core dump文件的路径污染，可以把内容写到任意位置）。更危险的是/sys下的设备接口，比如/sys/class/backlight这类，虽然对普通服务威胁不大，但配合其他漏洞就可能变成攻击链的一环。

ProtectKernelTunables=true会把/proc/sys、/proc/sysrq-trigger、/proc/latency_stats等设为只读，ProtectKernelModules=true则会阻止模块的加载和卸载——这个参数直接被systemd映射为对/proc/modules、/sys/module的写保护，实际底层是禁止了init_module和finit_module相关的操作路径。ProtectControlGroups=true则是把/sys/fs/cgroup设为只读，防止进程操纵cgroup去影响其他进程的资源分配。

这三个参数我都建议一律开启。它们对正常服务几乎没有负面影响，但拦住了一大类"通过内核接口搞事情"的攻击手法。唯一需要留意的是，如果你跑的服务本身需要调整内核参数，或者你用了某些基于cgroup的用户态管理工具，那就得评估一下冲突，通常这种情况很少见。

PrivateDevices=true也是一个被低估的参数。它会给服务创建一个只有/dev/null、/dev/zero、/dev/random、/dev/urandom、/dev/tty这几个最基本设备节点的最小/dev，也就是说进程看不到硬盘设备（/dev/sda等）、看不到显卡、看不到USB设备。这直接拦截了一大类"访问原始设备"的攻击手段。很多服务其实只需要随机数生成器，这个参数几乎是无痛的。

2.3 能力裁剪：CapabilityBoundingSet与NoNewPrivileges

Linux的capabilities机制，通俗理解就是把root的"超级权限"拆分成互相独立的小权限块。进程虽然以root运行，但如果没有对应的capability，就干不了对应的特权操作。举个例子，CAP_NET_BIND_SERVICE负责绑定1024以下端口，CAP_DAC_READ_SEARCH负责绕过文件读写权限检查，CAP_SYS_ADMIN则是一堆系统管理操作的总开关——这是Linux中权限最大的capability之一，跟整个挂载命名空间、特权操作都有关联。

CapabilityBoundingSet=可以直接裁剪掉进程未来可能获得的所有capability。比如一个Nginx服务，它只需要绑定80端口和写日志文件，那理论上只需要CAP_NET_BIND_SERVICE就够了。你可以这么写：

code复制CapabilityBoundingSet=CAP_NET_BIND_SERVICE

这样即使攻击者拿到了服务进程的代码执行权限，他们也办法通过setuid来拿回capability，也没有能力去执行那些需要特权才能做的事。

但这里有一个常见的错误：很多人只设置CapabilityBoundingSet，却不设置AmbientCapabilities，然后发现服务无法绑定80端口了。原因是，systemd启动服务后进程默认所有capability清空，除非你用AmbientCapabilities把需要的capability"放回去"。而且，有些场景下服务的可执行文件自身没有file capability时，这些放回去的capability在execve之后依然能保留，这就是AmbientCapabilities的设计目的。

我通常是这样搭配的：

code复制CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE

其中CapabilityBoundingSet决定了这个进程以及它所有子进程的capability上限，AmbientCapabilities则在进程启动时把它需要的capability放到permitted集合里，并且能在execve之后保留。

再看NoNewPrivileges=true，这个参数的含义是禁止进程及其子进程通过execve获得新的权限。它直接禁用了setuid、setgid这类二进制文件的提权机制，也禁用了user namespace相关的提权路径。这个参数的价值在于，即使你的服务里存在一个能执行任意二进制程序的漏洞，攻击者也没法通过执行/usr/bin/passwd、/bin/su这类setuid程序来提权。NoNewPrivileges在Systemd沙箱里几乎是"必须有"级别的配置。

2.4 系统调用过滤：SystemCallFilter与RestrictAddressFamilies

系统调用（syscall）是用户态进程请求内核服务的唯一入口。Systemd的SystemCallFilter=参数允许你直接限制进程能使用的系统调用集合，底层走的是seccomp机制。

seccomp的过滤粒度比capability更细，capability管的是"能不能做某类特权操作"，syscall过滤管的是"能不能触发某个内核功能"。比如CAP_SYS_ADMIN已经被裁剪掉了，那mount这个系统调用的权限本来就会被拒绝；但如果你还想禁止进程创建新进程（clone/fork），那就需要SystemCallFilter=~@process这类写法了。

SystemCallFilter=有两种前缀模式：默认是白名单模式，只允许列表内的系统调用；加~前缀表示黑名单模式，禁止列表内的系统调用，其余放行。Systemd预置了一组分组，比如@network-io（网络IO相关的系统调用）、@file-system（文件系统相关的系统调用）、@process（进程管理相关的系统调用）、@privileged（特权相关系统调用）、@obsolete（几乎没人用的过时系统调用）。

以Web服务为例，一个比较稳的黑名单方案：

code复制SystemCallFilter=~@privileged @obsolete @setuid @debug @cpu-emulation

这样就把特权调用、过时调用、setuid类调用、调试类调用（比如ptrace）全部挡掉了。

再配合RestrictAddressFamilies=，这个参数限制进程能使用的socket地址族，一般服务只需要AF_INET和AF_UNIX就够了：

code复制RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX

加上这个之后，进程想创建AF_PACKET套接字去做原始网络包抓取，直接被拒。像上面这种组合，会让攻击者很难在服务进程里做横向移动。

MemoryDenyWriteExecute=true也是值得养成的习惯。这个参数直接把"写内存"和"执行内存"在同时具备的情况禁止了——也就是说进程无法创建可写可执行的内存页。攻击者如果想把shellcode写入内存后跳转执行，这一步会受到显著阻碍。代价是，任何依赖JIT（比如Node.js的V8引擎、Java的JVM）的服务可能会受到性能影响或直接崩溃。所以如果你跑的是Node.js服务，这个参数要自己权衡，通常建议用MemoryDenyWriteExecute=true配合Node的--jitless模式评估一下能不能接受损失。

3. systemd-analyze security：一条命令给服务安全打分

3.1 怎么读安全审计报告

Systemd内置了一个安全审计工具，不需要额外安装：

bash复制systemd-analyze security nginx.service

运行之后，它会输出类似下面的内容：

code复制→ Overall exposure level for nginx.service: 9.6 EXPOSED

然后是一大串Exposure级别的逐项分析：

每一行都有一个权重。系统的总体暴露等级是把所有"未设置"的权重加起来计算的，0到10区间里，越接近10说明暴露面越大。如果所有安全选项都开到最严格，理论上能达到0.0，但实际业务几乎不可能做到满分，大多数场景下，跑到3.x或者4.x已经算是非常稳健了。

用这个工具还有一个技巧：它是逐项评价，而不是笼统打分。你可以先跑一遍，看哪一项"拖后腿"最严重，优先处理权重高的项。比如PrivateNetwork权重0.5，PrivateDevices权重0.5，ProtectSystem权重0.2——先把权重高的解决了，分数的下降立竿见影。

3.2 结合业务评估暴露面

但这里必须澄清一个理念：systemd-analyze security的分数不是"越高越好"或者"越低越好"，而是"越低越安全，但也要兼顾可用性"。比如你跑一个需要接受外部连接的Web服务，就不能开PrivateNetwork=true（会失去网络），不能开ProtectSystem=strict如果它需要写缓存目录，不能开MemoryDenyWriteExecute=true如果它依赖JIT。

所以实际流程应该是这样的：先用systemd-analyze security拉一个全量报告，然后逐项判断"这一项能不能开"，能开就开，不能开就跳过并记录原因，最后把改完的unit文件再跑一次评估，确认暴露等级降到了一个可接受的范围。

我见过一些团队把分数当作绩效考核指标，单纯追求0.0满分，结果服务频繁出问题，最后只能把安全参数全部回滚。这属于本末倒置。安全配置的目的是在不影响业务的前提下减少攻击面，它是"风险控制"，不是"文档成就"。

3.3 逐步加固的真实演示

拿一个常见的Node.js服务来演示，假设这是一个提供API接口的后端服务，不需要运行特权的端口，不需要读写系统敏感目录。

第一步，加固前直接运行扫描：

code复制# systemd-analyze security node-api.service
→ Overall exposure level for node-api.service: 8.7 EXPOSED

第二步，依次补齐能开的安全参数，每次改完都重新跑一次扫描。
先加文件系统保护：

code复制ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
PrivateDevices=true

扫描结果降到6.9。再加进程隔离：

code复制ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true
RestrictSUIDSGID=true

降到5.2。再加特权限制：

code复制NoNewPrivileges=true
CapabilityBoundingSet=

降到4.1。最后加系统调用和网络限制：

code复制SystemCallFilter=~@privileged @setuid @obsolete
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX

最终停在3.3左右。整个过程，业务没受影响，API的响应速度也没有感知到的改变，但攻击面的减少是实打实的。

4. 实战：用最小配置把服务锁进"保险箱"

4.1 完整Unit文件示例

理论说了一堆，最后落地的还是unit文件本身。我给出一个接近生产可用的完整配置模板，用Nginx做例子。这个配置结合了文件系统保护、内核接口保护、能力裁剪、系统调用过滤和资源限制。

ini复制[Unit]
Description=My Nginx Service
After=network.target

[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/bin/nginx -t -q -g 'daemon on; master_process on;'
ExecStart=/usr/bin/nginx -g 'daemon on; master_process on;'
ExecReload=/usr/bin/nginx -s reload
ExecStop=/usr/bin/nginx -s quit

# 文件系统保护
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
PrivateDevices=true
ReadWritePaths=/var/cache/nginx /var/log/nginx /run

# 内核接口保护
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true
RestrictSUIDSGID=true

# 特权与能力
NoNewPrivileges=true
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE

# 系统调用与网络
SystemCallFilter=~@privileged @setuid @obsolete @debug
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
LockPersonality=true

# 资源限制
MemoryDenyWriteExecute=true
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

这个配置有几个点需要解释一下。ReadWritePaths是ProtectSystem=strict的配套放行项。Nginx需要写/var/log/nginx/下的日志、/var/cache/nginx/下的缓存、/run下的pid文件，所以要把这些路径重新挂载为可写，其他路径保持只读。

Type=forking是Nginx经典的启动风格，所以需要配PIDFile让systemd能定位到主进程。MemoryDenyWriteExecute=true对Nginx是安全的，因为Nginx不使用JIT。

LockPersonality=true是很多人不常注意的参数，它阻止进程修改自己的"执行域"（personality），防止攻击者利用personality系统调用改变进程行为来绕过某些安全机制。默认推荐直接开启。

改动完成后，执行：

bash复制systemctl daemon-reload
systemctl restart nginx

然后跑一次systemd-analyze security nginx.service，观察暴露等级的变化。正常情况能从裸奔的9.x降到3.x附近。

4.2 验证服务和确认功能没有受损

改完安全参数之后，最怕的是业务悄悄出问题。所以必须做一些基础的验证动作。第一，检查服务状态和进程是否正常存活；第二，实际请求一次服务接口，确认返回结果正常；第三，异常情况下看journal日志是否有权限报错：

bash复制systemctl status nginx
curl -I http://127.0.0.1/
journalctl -u nginx.service -n 50 --no-pager

有一个坑我在生产环境踩过：ProtectSystem=strict + ReadWritePaths虽然放行了路径，但如果ReadWritePaths指向的目录在运行时不存在（比如某些日志目录是延迟创建的），systemd启动时会直接报错。这时候要么提前用ExecStartPre把目录创建好，要么在unit里用RuntimeDirectory=声明需要自动创建的目录。RuntimeDirectory=nginx会在/run/nginx下自动建目录，同时清理策略也更健壮。

如果你在加固中发现某个服务确实需要更多的capability，可以通过systemctl show <service> -p CapabilityBoundingSet来查看当前生效的值，再决定怎么调整。

4.3 动态验证沙箱是否真的生效

很多人加了配置之后心里没底，想知道沙箱是不是真的起作用了。其实有几个快速验证的手段。

第一个是用systemd-analyze security看各个安全项的评估结果，确认"未设置"变成了对应的保护级别。第二个是直接用systemctl show看服务进程的运行时属性：

bash复制systemctl show nginx -p NoNewPrivileges -p ProtectSystem -p PrivateTmp

第三个是更直白的入侵模拟。比如你想验证ProtectHome=true是否生效，可以临时给服务加一个ExecStartPost来尝试读取/root目录，如果被拒绝了就说明生效。但生产环境我不会这么做，更安全的做法是用systemd-run临时跑一个相同沙箱配置的进程做验证：

bash复制systemd-run --property=ProtectHome=true --property=PrivateTmp=true /bin/bash -c "cat /root/secret.txt"

如果输出Permission denied，说明保护在正常工作。这类"验证性攻击"比单纯看配置要踏实得多。注意systemd-run跑完后是一次性任务，会直接返回结果，很适合做验证。

5. 常见问题与排查技巧实录

5.1 WSL里的Systemd用户会话报错

回到开头那条报错：

code复制wsl: failed to start the systemd user session for 'root'. see journalctl for details

这个问题在Windows Subsystem for Linux（WSL）里比较常见，核心原因是systemd的用户会话依赖于user manager（user@1000.service）和D-Bus，而WSL环境下默认的session情况比较特殊。如果你是在WSL里跑Systemd（需要启用systemd=true选项），出现这个报错不影响大多数服务，可以忽略；但如果影响到了你需要使用的用户级服务，可以先确认D-Bus是否正常启动：

bash复制systemctl --user status

或者查看journal里的具体报错信息：

bash复制journalctl --user -b

这个问题的本质是systemd会把用户实例当作一个独立的"session"来管理，而在WSL这种非标准启动环境中，login会话的初始化流程可能没有完整走一遍。如果你在WSL里主要用systemd做系统级服务实验，不需要太关心这个报错。

5.2 报错"could not set file security for file"

这个报错经常出现在启用了SELinux的系统上，但有时候在普通发行版上也会冒出来。它的核心问题是：systemd在启动服务进程之前，需要对一些文件设置安全上下文（security context），如果文件系统不支持这个操作，或者进程缺少相应权限，就会报这个错。

排查思路分三步。第一步，看文件系统挂载参数：

bash复制mount | grep " / "

确认是不是用了noacl之类的挂载参数。第二步，如果是SELinux系统，检查SELinux状态：

bash复制getenforce

如果处于Enforcing模式，看一下/var/log/audit/audit.log里有没有avc denied记录。第三步，如果都不是，检查你服务的WorkingDirectory和RuntimeDirectory指向的路径是否属于只读文件系统。这个问题最坑的地方在于，报错信息可读性很差，很多人会以为是权限问题，反复chmod和chown，最后发现根本不是那回事。

5.3 加固后服务起不来的通用排查思路

安全参数加得越多，服务起不来的概率越高。这个规律几乎无法避免，所以排查方法比记忆单个参数更重要。

先看服务状态：

bash复制systemctl status myservice

不要只看最后几行，要结合journalctl -u myservice -n 100完整地看一遍启动日志。常见情况有这些：ProtectSystem=strict导致服务启动时需要写某个没放行的路径，日志里会出现Read-only file system字样；SystemCallFilter过于激进导致执行ExecStartPre时就挂了，日志里会有Operation not permitted；CapabilityBoundingSet裁剪掉了服务需要的CAP_NET_ADMIN等capability，日志里会出现socket: Operation not permitted。

有一个调试技巧：先用安全配置跑一次systemd-run，用-p参数挂上可疑的安全项，把进程调到前台观察输出。比如：

bash复制systemd-run --user -p ProtectHome=true -p ProtectSystem=strict /usr/bin/myservice

这样前台直接暴露报错，比反复systemctl restart和看日志循环要高效得多。

5.4 性能影响评估

很多人在加安全配置之前会担心性能损失。从我的实测经验看，绝大多数Systemd沙箱参数对性能的影响可以忽略不计。

ProtectSystem、ProtectHome这类参数在进程启动时创建一次挂载命名空间，之后就没有额外开销了。SystemCallFilter走的是seccomp-BPF，每个系统调用会多一次BPF程序验证的开销，但这个开销是纳秒级的，除非你的服务每秒有百万级以上的系统调用量，否则感知不到。真正可能带来量化影响的是MemoryDenyWriteExecute，因为它会影响JIT引擎的内核行为，但这个影响在Web服务场景里通常也不明显。

反正我的原则是：安全参数优先开满，如果业务异常，再逐个排查回退，并且要弄清楚"为什么需要回退"。不要因为"担心性能"而在一开始就不开安全参数——绝大多数情况下，你的服务性能瓶颈不在安全层，而在业务逻辑、数据库和网络IO上。

6. 踩坑记录与系统化加固清单

6.1 踩过的坑：ReadOnlyPaths和ReadWritePaths的路径匹配问题

ReadWritePaths和ProtectSystem=strict组合使用时，路径匹配规则是"最长前缀匹配"。意思是如果你放行了/var/lib/app，但/var/lib/app/cache没有被显式放行，那么实际运行时/var/lib/app/cache还是按ProtectSystem=strict处理，是只读的。这个规则初看很容易踩坑，因为系统不会报错，只是运行时子目录写不进去。

我现在写unit文件，凡是涉及路径放行的，都会先列目录树结构，再决定需要放行哪些路径。如果你的服务逻辑是"整个目录都要写"，直接把路径写在ReadWritePaths里就行；如果只有子目录可写，父目录只读，那就不需要额外加父目录。

另一个相关的问题是BindPaths和BindReadOnlyPaths。这两个参数可以把宿主机上的文件bind-mount到服务的命名空间里。比如：

code复制BindPaths=/host/data:/data

这意味着服务看到的/data其实是宿主机的/host/data。这种"显式的bind mount"经常和ProtectSystem=strict一起出现，因为strict模式下整个根文件系统是只读的，你想给服务透传一个配置文件目录，就要用BindPaths或BindReadOnlyPaths引入可写区域。

6.2 系统化加固清单

综合所有经验，我整理了一个适合大多数服务的安全加固检查清单。严格按照这个顺序操作，能最大程度避免踩坑：

1. 先跑systemd-analyze security <service>记录基线分数。
2. 加上文件系统层保护：ProtectSystem=strict + ProtectHome=true + PrivateTmp=true + PrivateDevices=true，有需要的话配ReadWritePaths。
3. 加上内核接口保护：ProtectKernelTunables=true + ProtectKernelModules=true + ProtectControlGroups=true + RestrictSUIDSGID=true。
4. 加上权限限制：NoNewPrivileges=true + CapabilityBoundingSet=（按需放行）+ AmbientCapabilities=（如果确实需要绑定低端口等能力）。
5. 加上系统调用过滤：SystemCallFilter=~@privileged @obsolete @setuid @debug，不要一开始就把@file-system这类分组拉黑，很可能会导致服务崩溃。
6. 加上网络限制：RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX（如果服务只监听unix socket，可以把AF_INET也去掉）。
7. 加上内容保护：MemoryDenyWriteExecute=true（JIT服务慎用，先测性能）+ LockPersonality=true。
8. 重新跑一次systemd-analyze security，看暴露等级变化。
9. 重启服务，用真实请求验证业务功能无损。

这套清单里的每个参数，在systemd.exec手册里都有详细说明。建议你自己翻一遍，别完全依赖别人的配置示例。因为你自己的业务特性决定哪些参数能开哪些不能开，这个判断只能由你来做。

6.3 Systemd高级特性与沙箱的搭配

沙箱参数也不是孤立的，它和Systemd其他高级特性配合起来会有更好的效果。

PrivateUsers=true是一个值得单独说明的参数。它会为服务创建一个独立的用户命名空间，服务进程在用户命名空间内看到自己是root（uid 0），但实际上它在宿主机的uid是nobody（通常65534）或其他非特权用户。这对那些"启动脚本里硬编码了root路径"的服务很友好，因为它让进程以为自己有root权限，实际却不能触碰宿主机上的任何特权资源。代价是某些涉及CAP_SYS_ADMIN的操作会被阻止，需要提前验证。

RestrictRealtime=true阻止进程使用实时调度，RestrictNamespaces=true阻止进程创建新的namespace——这两个参数配合起来，能让攻击者难以把"已经拿到的权限"进一步扩散到系统其他部分。

IPAddressDeny和IPAddressAllow也是后来加进来的有用参数，它们基于BPF，可以在不配置独立网络命名空间的前提下，限制服务能访问的IP地址段。比如某服务只需要访问内网数据库：

code复制IPAddressAllow=192.168.1.0/24
IPAddressDeny=any

如果你管理的是一个有明确网络拓扑的服务集群，这两个参数非常实用。

7. 写在最后：一点加固背后的思路

我在实际操作中最深的感受是：Systemd的沙箱配置一点也不神秘，它就是把Linux内核里原本就有的安全机制——namespace、capabilities、seccomp、read-only bind mount——用一套声明式的配置暴露出来。难的不是理解每个参数，而是建立"用最小权限运行服务"的心智模型。

很多服务崩溃后回滚安全配置的案例，最后查下来都是同一个原因：配置参数和业务逻辑之间的约束关系没理清楚。比如Node.js服务需要MemoryDenyWriteExecute，但业务里某段代码用了不兼容的编译方法；再比如ProtectSystem=strict，但你没意识到服务启动时要动态写入配置文件。这些问题要靠测试和日志去发现，而不是靠"不加安全配置"来回避。

如果你刚开始接触这块，我建议不要一口气把所有参数全部加上去，那样出问题了根本不知道是哪一个参数引起的。正确的姿势是：先加文件系统保护，跑一遍业务测试；再加内核接口保护，跑一遍；再加能力和系统调用限制，再跑一遍。每加一层就验证一次，这样即使出了问题，你也能快速缩小范围，知道是哪一类参数导致的。

Systemd的安全机制是那种"平时感觉不到存在，出事时才知道有多重要"的东西。等哪天真发生了一次入侵或者恶意代码事件，你再回头看这些配置，就会觉得当时花的那几个小时，值回票价了。