Ubuntu安全通过systemd安全沙箱选项限制服务特权

Ubuntu 24.04 LTS 或最新的 22.04 系统上，systemd 早已不仅仅是启动管理器，它内置了一套极其强大的安全沙箱机制。很多运维人员习惯通过 AppArmor 或复杂的容器来限制服务权限，却忽略了就在手边的 systemd 单元配置。通过直接编辑服务单元文件，无需安装额外软件，就能将高风险服务的权限锁死在最小范围，直接阻断漏洞利用后的横向移动路径。

systemd 的安全指令并非简单的黑名单，它们直接调用 Linux 内核的命名空间和权能机制。理解这些指令的逻辑，就能像搭积木一样构建防护墙。关键指令包括：PrivateTmp（隔离临时目录）、ProtectSystem（锁定系统目录）、ProtectHome（屏蔽家目录）、NoNewPrivileges（禁止提权）、CapabilityBoundingSet（权能裁剪）以及更为激进的 DynamicUser 和 PrivateNetwork。这些配置直接写在服务的 [Service] 区块中，重启服务后立即生效，性能损耗极低。

绝大多数服务入侵事件，攻击者得手后的第一步就是浏览文件系统寻找敏感配置或密码。systemd 提供了多层级的文件系统隔离。首先是 ProtectSystem，它可以将 /usr、/boot 甚至 /etc 挂载为只读。设置 ProtectSystem=full 意味着 /usr 和 /etc 对服务进程不可写；设置为 strict 则连 /dev 等虚拟文件系统也会变为只读，除非通过 ReadWritePaths 显式放行。如果你的服务只需要写入特定日志目录，可以这样配置：

[Service]
ProtectSystem=strict
ReadWritePaths=/var/log/myapp /var/lib/myapp

其次是 ProtectHome，它直接决定了服务能否访问用户家目录。对于系统级服务，通常应设为 ProtectHome=true 或 read-only，彻底阻断通过家目录植入 SSH 密钥或读取敏感脚本的可能。还有一个容易被忽视的指令是 PrivateTmp。设为 true 后，服务会拥有独立的 /tmp 和 /var/tmp 目录，其他进程完全看不到它创建的临时文件。这能有效防御利用临时文件预测文件名进行的竞态攻击和会话劫持。

Linux 的 root 权限被细分为数十种权能。传统服务以 root 启动再降权，但初始阶段仍存在风险窗口。systemd 的 CapabilityBoundingSet 可以精确到只保留服务必需的权能，多一个都不给。例如，一个普通的 Web 服务不需要修改系统时间或加载内核模块。你可以通过 AmbientCapabilities 授予必需权能，再用 CapabilityBoundingSet 划死上限。更彻底的做法是结合 User 和 Group 指令，让服务以非特权用户运行，并配合 NoNewPrivileges=true。这个指令极其关键，它确保服务进程及其子进程永远无法通过 setuid 或权能提升获得新权限，哪怕二进制文件本身有 SUID 位，内核也会直接拒绝。这是堵死脏牛漏洞等本地提权漏洞利用的终极防线。

如果服务不需要网络，直接拔掉它的网线。PrivateNetwork=true 会为服务创建一个独立的网络命名空间，里面只有一个 loopback 回环接口，连物理网卡都看不见。这对于数据库维护脚本、本地定时任务等极其有用。如果服务需要监听端口但不想被外部访问，可以结合 IPAddressDeny 和 IPAddressAllow 做精细控制。另一个革命性的特性是 DynamicUser。设为 true 后，systemd 会在服务启动时动态分配一个高 UID 的临时用户，服务停止后该用户即被回收。这解决了静态非特权用户长期存在可能被其他服务利用的问题，同时配合 StateDirectory 和 CacheDirectory 等指令，systemd 会自动管理这些目录的所有权和权限，确保动态用户能读写持久化数据，而目录权限被严格限制为 0700。

设备文件是攻击者常用的逃逸通道。DeviceAllow 指令可以按字符设备或块设备的主次设备号进行白名单控制。例如，仅允许访问 /dev/null、/dev/zero 和 /dev/random，可以写为 DeviceAllow=/dev/null rw。更底层的防护是系统调用过滤。SystemCallFilter 指令利用内核的 seccomp 过滤器，直接限制进程能发起的系统调用集合。你可以定义一个白名单集，例如 @system-service（包含基本的系统调用）或 @network-io。如果服务逻辑固定，甚至可以手动枚举允许的调用号。一旦进程发起了白名单外的系统调用，内核会直接发送 SIGSYS 信号终止进程，并产生审计日志。这对于阻断利用怪异系统调用实现的漏洞利用代码有奇效。

假设我们有一个基于 Python 的 Web 后端服务，监听 8080 端口，需要读取 /etc/mylogin 下的配置文件，并向 /var/log/webapp 写入日志。传统部署可能直接以 root 运行，现在用 systemd 沙箱改造。创建 /etc/systemd/system/webapp.service 文件，内容如下：

[Unit]
Description=Secure Web Application
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/python3 /opt/webapp/app.py

User=webapp
Group=webapp
DynamicUser=yes

ProtectSystem=strict
ProtectHome=true
PrivateTmp=true
ReadWritePaths=/var/log/webapp
ReadOnlyPaths=/etc/mylogin

NoNewPrivileges=true
PrivateDevices=true
DeviceAllow=/dev/null rw
DeviceAllow=/dev/zero rw
DeviceAllow=/dev/random rw

CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE

SystemCallFilter=@system-service @network-io
SystemCallErrorNumber=EPERM

RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
RestrictRealtime=true
MemoryDenyWriteExecute=true

[Install]
WantedBy=multi-user.target

这套配置实现了什么效果？服务以动态生成的 webapp 用户运行，没有固定的 UID 残留。整个 /usr 和 /etc 只读，仅 /etc/mylogin 可读，/var/log/webapp 可写，其他路径完全不可见。临时目录隔离，设备访问仅限三个标准设备。进程无法获得新权限，即便代码有漏洞也无法提权。权能仅保留绑定低端口的能力，如果改用 8080 端口，连这个权能都可以去掉。系统调用被限制在基础服务和网络 IO 范围内，任何尝试调用奇怪系统调用的行为都会收到 EPERM 错误而非直接崩溃，便于调试。地址族限制在 IPv4、IPv6 和 Unix 套接字，禁止创建 Netlink 等可能用于逃逸的套接字类型。MemoryDenyWriteExecute 阻止了将内存页同时设为可写可执行，这是防范缓冲区溢出注入 shellcode 的硬件级防护。

配置完成后，执行 systemctl daemon-reload 并重启服务。验证沙箱是否生效不能仅凭服务正常运行就了事。需要进入服务的命名空间内部查看。使用 systemd-cgls 找到服务的 cgroup 路径，或直接通过 /proc 查看。更直接的方法是使用 nsenter 结合服务的主进程 PID 进入其命名空间。例如，查看其挂载信息：nsenter -t PID -m mount，你会看到 /usr 被挂载为只读的 overlay，/tmp 是一个全新的空目录。查看网络：nsenter -t PID -n ip addr，如果设置了 PrivateNetwork，只会看到 lo 接口。还可以使用 systemd-analyze security 服务名 来获得一份安全评分和详细的漏洞分析报告。这个工具会逐项检查你的单元文件配置，指出未启用的加固选项和潜在风险，并给出具体的改进建议，是调优沙箱配置的利器。

有人担心层层过滤会影响性能。实测表明，文件系统命名空间挂载点的创建仅在服务启动时发生一次，运行时开销几乎为零。seccomp 过滤器在内核中通过 BPF 程序执行，每次系统调用增加几十纳秒级检查，对 IO 密集型或计算密集型服务的影响微乎其微。唯一需要注意的是 DynamicUser 会为每个服务实例创建独立的 UID 映射，如果一台机器上运行数百个此类服务，可能需要调整 /etc/login.defs 中的 SUB_UID_COUNT 等参数预留足够的动态 UID 范围。对于确实需要高性能且经过严格审计的服务，可以适当放宽文件系统保护，但 NoNewPrivileges 和 CapabilityBoundingSet 应始终启用，因为它们的开销完全可忽略，而安全收益巨大。

在容器化和编排层盛行的今天，systemd 沙箱的价值在于为宿主机上的基础组件提供最后一道防线。比如 kubelet、containerd、etcd 这些 Kubernetes 核心组件，它们本身运行在宿主机上，无法被容器运行时隔离。通过为这些关键服务编写加固的 systemd 单元，可以防止单个容器逃逸后直接控制整个节点。将上述沙箱配置模板化，通过 Ansible 或 cloud-init 在节点初始化时统一部署，是构建零信任基础设施的基石。记住，安全不是一层屏障，而是多层防御。systemd 沙箱就是那层最贴近内核、最容易被忽视却极其有效的硬隔离。