Linux容器安全实战：非特权容器与Seccomp联合防御指南

1. 容器安全基石：从特权到非特权的范式转变

在容器技术普及的今天，安全隔离不再是“锦上添花”，而是“生死攸关”的核心需求。很多刚接触容器的朋友，可能都是从 sudo lxc-create 或 docker run 开始的，默认情况下这些操作都需要 root 权限。这背后隐藏着一个巨大的风险：一旦容器内的进程突破隔离，它将直接拥有主机上的 root 权限，后果不堪设想。这就是“特权容器”的典型困境。

那么，有没有办法让一个普通用户也能安全地创建和管理容器，同时即使容器被攻破，攻击者也拿不到主机的高权限呢？答案是肯定的，这就是“非特权容器”要解决的核心问题。它的实现，完全依赖于 Linux 内核中一个看似低调却威力巨大的特性：用户命名空间。

简单来说，用户命名空间为进程提供了一套独立的用户和组 ID 映射视图。在容器内部，进程可以认为自己是以 root（UID 0）身份运行的，但这个“root”只是一个虚拟身份。内核通过一个映射规则，将这个容器内的 UID 0 映射到主机上的一个普通、无特权的用户 ID（比如 UID 100000）。这样一来，即便容器内的“root”想干坏事，它在主机上实际操作的权限也被限制在了映射后的那个普通用户范围内，攻击面被大幅压缩。

这不仅仅是理论。从 LXC 1.0 版本开始，非特权容器的支持就已经相当成熟。我过去在构建多用户开发环境或部署不可信应用时，非特权容器是首选的底层隔离方案。它从根本上改变了容器的安全模型，从“信任容器内的 root”转变为“不信任任何容器进程”，这是构建坚实安全防线的重要一步。

2. 非特权容器实战：从零构建安全沙箱

纸上得来终觉浅，绝知此事要躬行。下面，我将带你一步步配置一个完整的非特权 LXC 容器环境。这个过程涉及主机系统配置、用户映射、网络设置等多个环节，我会在每个关键点解释其背后的原理和注意事项。

2.1 主机系统与依赖检查

在开始之前，我们必须确保主机内核支持必要的功能。运行 lxc-checkconfig 命令是必不可少的第一步。这个脚本会检查内核是否启用了所需的命名空间（user, pid, net, ipc, uts, mnt）、cgroups 以及相关的安全模块。

注意：很多发行版的内核默认启用了这些功能，但自定义内核或某些云主机镜像可能需要额外配置。如果 lxc-checkconfig 报告缺少 user_namespaces ，你需要重新编译内核并启用 CONFIG_USER_NS=y 。这是非特权容器的生命线，没有它，后续所有步骤都无法进行。

除了内核，还需要确保 lxc 和 lxc-templates 软件包已安装，并且版本在 1.0 以上。你可以通过 lxc-info --version 来确认。

2.2 配置用户ID映射：安全隔离的核心

这是非特权容器配置中最关键的一步。我们需要为主机上的一个普通用户分配一段从属的用户ID（UID）和组ID（GID）范围。容器内使用的 UID/GID 将映射到这个范围内。

第一步，创建映射文件。 这两个文件可能不存在，需要手动创建并设置正确的权限。

for file in '/etc/subuid' '/etc/subgid'; do
    sudo touch $file
    sudo chown root:root $file
    sudo chmod 644 $file
done

/etc/subuid 和 /etc/subgid 的权限必须是 root:root 和 644 ，以防止非特权用户篡改他人的映射范围。

第二步，创建容器管理用户。 我们创建一个专门用于管理容器的用户 lxc-user ，并为其设置密码。

sudo useradd lxc-user -p $(echo 'your_secure_password' | openssl passwd -1 -stdin)

这里使用 openssl 生成加密后的密码。在生产环境中，更安全的做法是创建用户时不设密码（ -p '' ），然后仅通过 SSH 密钥或 sudo 切换到该用户。

第三步，分配从属ID范围。 检查 /etc/subuid 和 /etc/subgid 文件。在一些现代发行版（如 Ubuntu 18.04+）上，使用 useradd 添加用户时可能会自动分配。如果没有，我们需要手动分配。

sudo usermod --add-subuids 100000-165535 lxc-user
sudo usermod --add-subgids 100000-165535 lxc-user

这条命令为用户 lxc-user 分配了从 100000 到 165535 的 65536 个从属 UID 和 GID。这意味着， lxc-user 可以在自己的用户命名空间内创建最多 65536 个“虚拟用户”，这些用户的 ID（0-65535）会被映射到主机的 100000-165535。例如，容器内的 root（UID 0）在主机上实际是 UID 100000。

实操心得：范围大小的选择有讲究。65536（即 2^16）是一个常用值，足以满足绝大多数容器内用户管理的需求。如果你需要运行像 PostgreSQL 这类会在容器内创建系统用户的软件，确保范围足够大。同时，要确保不同用户的从属 ID 范围不能重叠，否则会导致权限混乱和安全问题。

2.3 网络与存储配置：打通容器与外界

非特权容器默认无法创建物理网络设备（如 veth 对或 tap 设备）。我们需要预先为其配置好网络。

创建网桥并配置。 我们创建一个名为 br0 的网桥，并为其分配一个 IP 地址，作为容器的网关。

sudo brctl addbr br0
sudo ip addr add 10.0.0.1/24 dev br0
sudo ip link set br0 up

这里我使用了 ip 命令替代老旧的 ifconfig ，它是更现代和推荐的工具。 10.0.0.1/24 是网桥的 IP，后续容器的 IP 可以配置为同一网段（如 10.0.0.100 ）。

授权用户使用网络设备。 通过 /etc/lxc/lxc-usernet 文件，我们可以控制每个非特权用户可以创建多少虚拟网络设备，并连接到哪个网桥。

echo "lxc-user veth br0 10" | sudo tee /etc/lxc/lxc-usernet

这行配置的含义是：用户 lxc-user 允许创建类型为 veth 的网络设备，最多可以创建 10 个，这些设备可以连接到名为 br0 的网桥。这为非特权用户提供了必要的网络能力，同时又施加了配额限制。

2.4 容器运行时配置与启动

现在，我们切换到 lxc-user 用户来配置和启动容器。

创建用户专属配置目录和默认配置。

sudo -u lxc-user mkdir -p /home/lxc-user/.config/lxc

LXC 会为每个用户在其家目录下寻找配置文件。接下来创建默认配置文件：

cat << EOF | sudo -u lxc-user tee /home/lxc-user/.config/lxc/default.conf
lxc.network.type = veth
lxc.network.link = br0
lxc.network.flags = up
lxc.network.ipv4 = 10.0.0.100/24
lxc.network.ipv4.gateway = 10.0.0.1
lxc.id_map = u 0 100000 65536
lxc.id_map = g 0 100000 65536
EOF

这个配置文件定义了容器的基本属性：

• lxc.network.* : 配置容器使用 veth 虚拟网卡，连接到主机网桥 br0 ，并设置静态 IP 和网关。
• lxc.id_map : 这是核心映射配置。 u 0 100000 65536 表示将容器内的 UID 0-65535 映射到主机的 UID 100000-165535。GID 映射同理。

配置cgroup委托（可选但重要）。 为了让非特权用户能管理自己容器的资源（CPU、内存等），需要将对应的 cgroup 目录权限委托给该用户。这步操作需要在 root 下进行。

# 启用 memory cgroup 的层级化记账（某些系统需要）
echo 1 | sudo tee /sys/fs/cgroup/memory/memory.use_hierarchy

for c in $(ls /sys/fs/cgroup/); do
    # 启用子cgroup继承父cgroup属性
    echo 1 | sudo tee /sys/fs/cgroup/$c/cgroup.clone_children 2>/dev/null || true
    # 为用户创建专属cgroup目录并更改所有者
    sudo mkdir -p /sys/fs/cgroup/$c/lxc-user
    sudo chown -R lxc-user:lxc-user /sys/fs/cgroup/$c/lxc-user
done

注意事项：并非所有 cgroup 控制器都支持非特权写入（尤其是 devices 控制器）。在较新的系统（使用 cgroup v2 或 systemd 管理的 cgroup）上，这一步可能有所不同，更推荐通过 systemd 的 Delegate= 属性来委托控制权。如果遇到权限错误，需要检查你的系统使用的是 cgroup v1 还是 v2 ( mount | grep cgroup )，并查阅对应文档。

登录用户并关联cgroup。 在新终端或通过 su 登录 lxc-user 用户后，需要将当前 shell 进程加入到我们刚才创建的 cgroup 目录中，这样后续由这个 shell 启动的容器进程才会继承这些 cgroup 设置。

for c in $(ls /sys/fs/cgroup/); do
    echo $$ > /sys/fs/cgroup/$c/lxc-user/tasks 2>/dev/null || true
done

$$ 代表当前 shell 的进程 ID。这个操作将当前会话“放置”在用户专属的 cgroup 树下。

创建并启动容器。 现在，一切准备就绪。我们可以创建一个 BusyBox 容器作为测试。

lxc-create -n my-unpriv-container -t download -- --dist ubuntu --release focal --arch amd64

这里我使用了 download 模板，它可以从官方镜像仓库拉取预构建的根文件系统，比古老的 busybox 模板更实用。 -n 指定容器名， --dist , --release , --arch 指定镜像详情。

创建完成后，启动容器：

lxc-start -n my-unpriv-container -F -d

-F 表示前台运行（结合 -d 则是后台启动后，将控制权交还终端）。此时，你可以用 lxc-attach 进入容器，或用 lxc-ls --fancy 查看状态。在容器内执行 whoami ，你会看到 root ，但回到主机用 ps aux | grep container-process 查看，该进程的实际用户是 lxc-user （或其映射的从属ID），这就是用户命名空间在起作用。

3. Seccomp深度解析：为容器穿上系统调用的“紧身衣”

如果说用户命名空间是从用户权限维度进行隔离，那么 Seccomp（Secure Computing Mode）就是从系统调用接口维度进行加固。一个进程即使突破了某种隔离，如果它无法调用关键的系统调用（如 mount , ptrace , reboot ），其破坏力也将被极大限制。

3.1 Seccomp的工作原理与模式演进

Seccomp 最初（模式1）是一种极其严格的沙箱，进程只能调用 read , write , exit , sigreturn 这四个系统调用，这几乎只能用于最简单的计算任务。显然，这对于容器这样需要运行完整应用的环境来说太不实用了。

Seccomp-BPF（模式2）的到来改变了游戏规则。它基于内核的 Berkeley Packet Filter (BPF) 机制，允许我们编写一个过滤程序（BPF 程序），为每一个系统调用及其参数定义精细化的策略。当进程发起系统调用时，内核会执行这个 BPF 程序来决定其命运，返回以下动作之一：

• SECCOMP_RET_KILL : 立即终止进程（ SIGSYS ）。
• SECCOMP_RET_TRAP : 向进程发送 SIGSYS 信号，可用于调试。
• SECCOMP_RET_ERRNO : 返回一个指定的错误码，而不执行系统调用。
• SECCOMP_RET_TRACE : 通知调试器（如 ptrace ），可用于动态分析。
• SECCOMP_RET_ALLOW : 允许该系统调用执行。

为了简化 BPF 程序的编写， libseccomp 库被开发出来。它提供了一套友好的 API，让开发者可以用系统调用的名字（而非晦涩的编号）和规则动作来定义策略，并由库负责生成底层的 BPF 代码。LXC 正是通过 libseccomp 来集成 Seccomp 支持的。

3.2 为LXC容器配置Seccomp策略

LXC 允许我们通过一个配置文件为容器指定 Seccomp 策略。这个策略会在容器的 init 进程启动时加载，并被子进程继承。

第一步，编写Seccomp策略文件。 策略文件有版本之分。我们使用更灵活、可读性更强的版本2。创建一个文件，例如 /var/lib/lxc/my-secure-container/seccomp.conf ：

2
blacklist
[all]
kexec_load errno 38
init_module errno 1
finit_module errno 1
delete_module errno 1
ioperm trap
iopl trap
open_by_handle_at kill

让我们逐行解析：

1. 2 : 第一行必须是版本号， 2 代表使用基于名称和黑名单/白名单的策略格式。
2. blacklist : 策略类型。 blacklist 表示“默认允许，明确列出的拒绝”； whitelist 则表示“默认拒绝，明确列出的允许”。对于容器，通常从 blacklist 开始，只禁用已知的危险调用。
3. [all] : 架构标签。 [all] 表示此规则适用于所有架构。你也可以针对特定架构，如 [x86_64] 或 [arm] ，这使得策略文件可以跨平台复用。
4. 后续每一行定义一个系统调用及其动作。格式是： 系统调用名称 [动作] 。动作可以是 kill , trap , errno <错误码> , allow 。如果省略动作，在 blacklist 策略下默认为 kill ，在 whitelist 下默认为 allow 。

上面这个策略示例：

• 禁止了加载新内核（ kexec_load ）、插入内核模块（ init_module , finit_module , delete_module ），这些是容器绝对不应该有的能力，返回错误码（ EPERM=1 , ENOSYS=38 ）。
• 禁止了直接操作 I/O 端口（ ioperm , iopl ），这些调用可能影响主机硬件，使用 trap 动作便于监控。
• 禁止了 open_by_handle_at 并直接 kill 进程。这个调用是著名的“Shocker”漏洞利用的向量，直接干掉进程更安全。

第二步，在容器配置中启用Seccomp。 编辑你的容器配置文件（例如 /var/lib/lxc/my-secure-container/config 或用户容器的 ~/.config/lxc/my-secure-container.conf ），添加一行：

lxc.seccomp = /var/lib/lxc/my-secure-container/seccomp.conf

对于非特权用户容器，策略文件路径需要放在用户有权限读取的位置，例如 /home/lxc-user/.config/lxc/seccomp.conf ，并在配置中引用绝对路径。

第三步，启动容器并验证。 启动配置了 Seccomp 的容器后，你可以进入容器验证策略是否生效：

# 在容器内尝试一个被禁止的系统调用，例如通过strace运行一个需要该调用的命令
# 或者，更直接地，检查容器的 init 进程状态
lxc-start -n my-secure-container -F -d
# 在主机上找到容器 init 进程的 PID
CONTAINER_PID=$(lxc-info -n my-secure-container -p | awk '/PID:/ {print $2}')
cat /proc/$CONTAINER_PID/status | grep Seccomp

如果输出 Seccomp: 2 ，说明 Seccomp 过滤模式（模式2）已生效。如果输出 Seccomp: 0 ，则表示未加载策略。

3.3 Seccomp策略编写经验与避坑指南

编写一个有效的 Seccomp 策略并非易事，过于宽松则形同虚设，过于严格则会导致应用崩溃。以下是我在实践中总结的经验：

1. 从宽松开始，逐步收紧。 不要一开始就写一个极度严格的白名单策略。先使用黑名单，只禁用那些公认危险的系统调用（如内核模块相关、调试相关、系统控制相关）。运行你的应用，观察其行为。使用 strace 或 perf trace 来监控容器进程实际使用了哪些系统调用。

# 在主机上跟踪容器进程
sudo strace -p $CONTAINER_PID -f -e trace=%process,%file,%network 2>&1 | head -50

2. 利用现成的策略模板。 LXC 源码包或安装目录中通常自带一些示例策略文件，例如 /usr/share/doc/lxc/examples/seccomp-* 。其中 common.seccomp 文件是一个很好的起点，它禁用了许多常见的安全敏感调用。你可以基于此文件进行增删。

3. 注意架构差异。 系统调用编号和名称在不同 CPU 架构上可能不同。 libseccomp 和 LXC 的策略文件（版本2）通过架构标签 [arch] 和系统调用名称解决了可移植性问题。但你在编写时仍需注意，某些系统调用可能只在特定架构上存在。使用 [all] 标签是安全的，但针对特定架构的优化可以更精确。

4. 性能考量。 Seccomp-BPF 过滤器在每次系统调用时都会执行。策略文件中的每一条规则都会转换为 BPF 程序中的判断语句。规则越多、越复杂，性能开销就越大。对于高性能敏感型应用，需要权衡安全与性能。通常，几十条规则的策略带来的开销是微乎其微的，但包含数百条复杂参数检查的规则则需测试。

5. 处理“未知”系统调用。 新的内核版本可能会引入新的系统调用。你的策略文件可能没有包含它们。在 blacklist 模式下，它们会被默认允许。在 whitelist 模式下，它们会被默认拒绝（导致 EPERM 或进程被杀死）。如果你追求极致安全并使用白名单，需要关注内核更新，并测试你的应用在新内核下的兼容性。

4. 非特权容器与Seccomp的联合防御实践

单独使用非特权容器或 Seccomp 都能提升安全性，但两者结合才能构建纵深防御体系。下面通过一个综合案例，展示如何为一个不可信的第三方应用部署安全的容器环境。

场景： 我们需要运行一个来自外部的、闭源的网络服务程序。我们对它的内部行为一无所知。

目标： 即使该程序含有恶意代码，也要将其破坏范围限制在容器内，并防止其进行高危操作。

实施步骤：

1. 创建专用的非特权用户和容器。 遵循第2章的步骤，创建一个专门用于运行此服务的用户，例如 app-user ，并分配从属ID。为其创建独立的网桥（如 br-app ）和网络配置，与其他容器网络隔离。

2. 编写针对性的Seccomp黑名单策略。 分析该网络服务可能的行为模式。作为一个网络服务，它不应该需要：

• 加载内核模块。
• 调试其他进程（ ptrace ）。
• 挂载文件系统（ mount , umount ）。
• 改变系统时间（ settimeofday , adjtimex ）。
• 创建特权进程（ clone 带有 CLONE_NEWUSER 等标志，但非特权用户本身无此能力，可作为额外防护）。
• 直接访问内核内存（ kexec , iopl ）。

我们可以基于 common.seccomp ，额外添加针对网络和进程间通信的严格限制，例如限制某些 socket 调用类型或 ipc 相关调用。策略文件可能如下：

2
blacklist
[all]
# 来自 common.seccomp 的常见危险调用
kexec_load errno 38
init_module errno 1
finit_module errno 1
delete_module errno 1
...
# 额外添加：禁止挂载、交换空间操作
mount errno 1
umount2 errno 1
swapon errno 1
swapoff errno 1
# 禁止某些网络操作（如果应用不需要）
acct errno 1
add_key errno 1
keyctl errno 1
request_key errno 1
# 对 open_by_handle_at 采取最严厉措施
open_by_handle_at kill

3. 结合cgroups限制资源。 在容器配置文件中，使用 cgroup 限制该容器的资源使用，防止其进行资源滥用攻击（如 Fork 炸弹、内存耗尽）。

# 在容器配置文件 (~/.config/lxc/app-container.conf) 中
lxc.cgroup.cpuset.cpus = 0-1      # 限制只使用前两个CPU核心
lxc.cgroup.memory.limit_in_bytes = 512M # 限制内存为512MB
lxc.cgroup.pids.max = 100         # 限制最大进程数为100

4. 配置只读根文件系统与绑定挂载。 如果应用不需要写入根文件系统，可以将其设置为只读，仅将必要的可写目录（如日志、临时文件）通过绑定挂载（ bind mount ）的方式从主机挂载进去。这可以防止应用篡改自身二进制文件或系统库。

# 在容器配置文件中
lxc.rootfs = /var/lib/lxc/app-container/rootfs
lxc.rootfs.options = ro
# 挂载一个可写的日志目录
lxc.mount.entry = /host/path/to/app/logs /var/lib/lxc/app-container/rootfs/var/log/app none bind,create=dir 0 0

5. 启动、测试与监控。 使用整合了 Seccomp 策略和资源限制的配置文件启动容器。

lxc-start -n app-container -F -d --logfile /tmp/app-container.log --logpriority DEBUG

密切监控容器日志 ( /tmp/app-container.log ) 和系统日志 ( journalctl -f )，查看是否有因 Seccomp 规则触发的进程终止或系统调用拒绝信息。使用 lxc-top 或直接查看 /sys/fs/cgroup/ 下的对应目录，监控容器的资源使用情况。

踩坑实录：我曾遇到一个应用在启用某个 Seccomp 策略后频繁崩溃，日志显示 Permission denied 。使用 strace 追踪发现，它频繁调用了一个名为 personality 的系统调用（用于设置进程执行域）。这个调用本身风险不高，但我的策略是白名单模式，没有包含它。解决方案是将 personality 加入白名单，或者直接改用黑名单模式，只禁用真正危险的调用。这个经历告诉我，白名单策略虽然安全，但维护成本高，需要深入理解应用行为；黑名单策略更易于实施，适合作为基线安全防护。

5. 高级安全加固与故障排查

将非特权容器和 Seccomp 用起来只是第一步。在生产环境中，我们还需要考虑更多维度的加固和面对各种问题的排查能力。

5.1 结合Linux Capabilities进行权限裁剪

用户命名空间将 root 映射成了普通用户，但容器内的进程仍然可能拥有一些不必要的 Linux 能力（Capabilities）。Capabilities 将 root 特权细分成了几十个独立的单元。我们可以进一步裁剪。 例如，一个 Web 服务器容器通常不需要 CAP_SYS_ADMIN （系统管理）、 CAP_NET_ADMIN （网络管理，除非需要配置网卡）等能力。在 LXC 配置中，可以这样设置：

lxc.cap.drop = sys_admin net_admin sys_module sys_time
lxc.cap.keep = net_bind_service

lxc.cap.drop 列出要丢弃的能力， lxc.cap.keep 列出要保留的能力（覆盖 drop 列表）。上例中，我们丢弃了多项管理能力，但保留了 net_bind_service ，允许容器内的进程绑定到 1024 以下的特权端口（如 80、443），这对于 Web 服务是必要的。

5.2 利用AppArmor或SELinux配置强制访问控制

Seccomp 控制“能做什么”（系统调用），而 AppArmor 或 SELinux 控制“能访问什么”（文件、网络、进程等）。它们是互补的。可以为容器加载一个定制的 AppArmor 策略文件，严格限制其文件系统访问路径、网络端口和协议等。 在 LXC 配置中指定：

lxc.apparmor.profile = lxc-container-default-cgns

或者使用一个自定义的配置文件路径。SELinux 的配置则通常通过容器运行时（如 Docker 的 --security-opt label=... ）或主机策略来管理。

5.3 常见问题与排查技巧

问题1：容器启动失败，报错“Failed to allocate network device”或“Permission denied”。

• 排查思路：
  1. 检查 /etc/lxc/lxc-usernet 配置是否正确，用户是否有权限创建指定数量的 veth 设备并连接到指定网桥。
  2. 检查网桥 br0 是否存在且已启动 ( ip link show br0 )。
  3. 对于非特权容器，确保使用的是用户自己的配置目录 ( ~/.config/lxc/ ) 和模板。有时使用系统模板 ( /usr/share/lxc/templates/ ) 会因为路径权限问题失败。

问题2：容器内进程无法写入某些文件，即使以 root 身份。

• 排查思路：
  1. 这是用户命名空间映射的典型表现。在主机上，使用 ls -n 查看该文件的真实所有者和组。假设文件属于主机 UID 1000。
  2. 在容器内，该文件的所有者 UID 是 1000 - 映射偏移量 。如果映射是 u 0 100000 65536 ，那么容器内看到的 UID 是 1000 - 100000 = -99000 ，这通常显示为一个巨大的数字或 nobody 。你需要确保文件在主机上的所有者 UID 落在容器的映射范围内，或者调整容器的 lxc.id_map 配置。

问题3：应用在容器内运行异常，怀疑被Seccomp规则阻断。

• 排查技巧：
  1. 查看日志 ：检查容器日志和系统日志 ( journalctl -k | grep seccomp 或 dmesg | tail )。
  2. 临时禁用Seccomp ：在容器配置中注释掉 lxc.seccomp 行，重启容器。如果问题消失，则确认是 Seccomp 导致。
  3. 使用 strace 进行动态分析 ：在主机上，以 root 权限 strace 跟踪容器进程，过滤 SECCOMP 相关错误。

  sudo strace -p $CONTAINER_PID -f -e trace=%seccomp 2>&1 | grep -i seccomp
  

  4. 调整策略动作 ：将可疑系统调用的动作从 kill 或 errno 改为 trap 。当该调用被触发时，进程会收到 SIGSYS 信号。你可以让应用 core dump，或者用调试器附加，从而精确定位是哪个库函数触发了该系统调用。
  5. 审查策略文件 ：使用 scmp_sys_resolver 工具（来自 libseccomp 包）检查系统调用名称在不同架构上是否正确。

  scmp_sys_resolver -a x86_64 open_by_handle_at
  

问题4：性能监控与调优。

• 监控Seccomp开销 ：使用 perf 工具可以观察系统调用的耗时。比较有/无 Seccomp 策略时，特定系统调用的执行时间差异。通常开销极小。
• 优化策略文件 ：将最常被拒绝的系统调用放在策略文件前面（BPF 程序是线性匹配的）。但更关键的是，确保策略是精确的，不要过度限制。使用黑名单时，只包含真正有威胁的调用。

安全是一个持续的过程，而非一劳永逸的配置。非特权容器和 Seccomp 为你提供了强大的工具，但最终的安全效果取决于你如何根据具体的应用场景和威胁模型去组合使用它们。从最小权限原则出发，逐步构建你的容器安全防线，并在实践中不断观察、测试和调整，这才是应对复杂安全挑战的正道。