Linux 容器隔离机制深度剖析：Namespace、Cgroup 与 Capabilities 的五层防御

引言

容器技术的本质是共享宿主内核的"隔离执行环境"。在 Linux 上，容器并非一种独立的内核技术，而是建立在 Namespaces（命名空间）、Control Groups（控制组）、Capabilities（能力）、Seccomp（安全计算模式）和 LSM（Linux 安全模块）之上的一套组合机制。从 Docker 到 Kubernetes，从 containerd 到 Podman，所有容器运行时最终都是通过这套 Linux 原语实现进程隔离。

本文深入剖析 Linux 隔离机制的实现细节：从 clone() 系统调用的 CLONE_NEW* 标志位开始，逐层解析 8 种 Namespace 的内核实现、cgroup v2 的资源限额模型、Capabilities 的权限拆分逻辑、Seccomp-BPF 的系统调用过滤机制，并讨论容器逃逸的常见路径与防御策略。

一、Linux Namespace：隔离的七重维度

Namespace 是 Linux 内核提供的一种"资源视图隔离"机制。每个 Namespace 将特定系统资源包装起来，使进程只看到属于该 Namespace 的资源子集。内核通过 struct nsproxy 将进程与一组 Namespace 关联：

// include/linux/nsproxy.h
struct nsproxy {
    atomic_t count;
    struct uts_namespace *uts_ns;      // UTS
    struct ipc_namespace *ipc_ns;      // IPC
    struct mnt_namespace *mnt_ns;      // Mount
    struct pid_namespace *pid_ns;      // PID
    struct net_namespace *net_ns;      // Network
    struct time_namespace *time_ns;    // Time (Linux 5.6+)
    struct cgroup_namespace *cgroup_ns; // Cgroup (Linux 4.6+)
    struct user_namespace *user_ns;    // User (Linux 3.8+)
};

1.1 PID Namespace：进程号的虚拟世界

PID Namespace 是最常用的隔离机制之一。在嵌套的 PID Namespace 中，每个进程在不同层级的 Namespace 中拥有不同的 PID：

宿主 Namespace:   PID 1 (systemd) ... PID 2345 (containerd) PID 2890 (bash)
容器 Namespace:   PID 1 (容器内 init) ... PID 10 (sshd) PID 15 (nginx)

内核中的映射嵌套关系：
Level 0（宿主）:   PID 2890
Level 1（容器）:   PID 1
Level 2（子容器）: PID 100（若存在更深层嵌套）

内核通过 struct pid_namespace 管理 PID 空间。关键设计包括：

• 层级深度：Linux 内核限制 PID Namespace 嵌套深度为 32 层（MAX_PID_NS_LEVEL）
• ID 映射：/proc/<pid>/uid_map 和 /proc/<pid>/gid_map 定义了 struct user_namespace 中用户 Namespace 之间的 UID/GID 映射关系
• PID 分配：每个 Namespace 独立使用 bitmap 跟踪 PID，alloc_pid() 递归地从当前 Namespace 向父 Namespace 逐层分配
• waitpid() 的可见性：在某个 PID Namespace 中，只能等待子 Namespace 中发来的信号，不能直接跨 Namespace 操作

1.2 Mount Namespace：文件系统视图的隔离

Mount Namespace 是容器镜像实现的基础。每个 Mount Namespace 拥有独立的文件系统挂载点列表，CLONE_NEWNS 标志位（clone() 或 unshare()）用于创建新的 Mount Namespace：

// 创建新的 Mount Namespace
unshare(CLONE_NEWNS);

// 关键数据结构：include/linux/mount.h
struct mnt_namespace {
    atomic_t count;
    struct ns_common ns;        // 通用 Namespace 结构
    struct mount *root;         // 当前根挂载点
    struct list_head list;      // 挂载点链表（按树形组织）
    struct user_namespace *user_ns;
    // ...
};

// 每个挂载点（mount）代表一个已挂载的文件系统实例
struct mount {
    struct hlist_node mnt_hash;
    struct mount *mnt_parent;       // 父挂载点（谁挂载了此挂载点）
    struct vfsmount mnt;            // VFS 挂载信息
    struct super_block *mnt_sb;     // 超级块
    struct list_head mnt_mounts;    // 子挂载点链表头
    struct list_head mnt_child;     // 兄弟链表节点
    // ...
};

容器的分层文件系统（OverlayFS）通过 Mount Namespace 实现：

// docker/overlay2 后端的工作方式：
lowerdir=/var/lib/docker/overlay2/l/xxx  (容器镜像只读层)
upperdir=/var/lib/docker/overlay2/xxx/diff (容器可写层)
workdir=/var/lib/docker/overlay2/xxx/work  (OverlayFS 工作目录)
merged=/var/lib/docker/overlay2/xxx/merged (合并视图，容器根文件系统)

// 实际挂载命令：
mount -t overlay overlay -o lowerdir=...,upperdir=...,workdir=... /merged

1.3 Network Namespace：网络栈的完整副本

Network Namespace 为容器提供独立的网络协议栈。创建 Network Namespace 后，该 Namespace 内最初只包含一个回环接口（lo），所有物理网卡、路由表、iptables 规则等都需要额外配置：

// 每个 Network Namespace的核心数据结构：net/net_namespace.h
struct net {
    atomic_t passive;    // 被动引用计数（即将销毁时置1）
    atomic_t count;      // 引用计数
    spinlock_t rules_mod_lock;
    struct list_head dev_base_head;     // 网络设备链表
    struct hlist_head *dev_name_head;   // 按设备名哈希
    struct hlist_head *dev_index_head;  // 按 ifindex 哈希
    struct sock *rt_cache;              // 路由缓存（已移除，使用 FIB TRIE）
    struct netns_ipv4 ipv4;             // IPv4 协议栈状态
    struct netns_ipv6 ipv6;             // IPv6 协议栈状态
    struct netns_tcp tcp;               // TCP 协议状态
    // ...
};

// 典型容器网络拓扑：
┌──────────────────────────────────────────────────┐
│ 宿主 Network Namespace                           │
│  ┌────────┐    ┌─────────┐    ┌────────┐        │
│  │ veth0  │────│ docker0 │────│  eth0  │────物理网│
│  │(host端)│    │  bridge │    │(宿主网卡)│        │
│  └────────┘    └─────────┘    └────────┘        │
│       │                                         │
└───────┼─────────────────────────────────────────┘
        │  (veth pair)
┌───────┼─────────────────────────────────────────┐
│  ┌────┴───┐                                     │
│  │ veth1  │   容器 Network Namespace           │
│  │(容器端) │   (PID Namespace + Mnt NS + ...)   │
│  └────────┘                                     │
│     └─── default route via docker0              │
└──────────────────────────────────────────────────┘

1.4 IPC Namespace：进程间通信隔离

IPC Namespace 隔离了 System V IPC 对象（消息队列、信号量、共享内存）和 POSIX 消息队列：

// IPC Namespace 核心结构：include/linux/ipc_namespace.h
struct ipc_namespace {
    refcount_t count;
    struct ipc_ids ids[IPC_SEM_IDS + 1]; // 分别管理 SEM/SHM/MSG
    struct user_namespace *user_ns;
    // 每种 IPC 资源都有独立的 ID 空间
};

// 在独立 IPC Namespace 中创建的 IPC 对象对外部不可见
// 同一 Namespace 内的进程可正常通信
$ ipcmk -Q          // 创建消息队列（在当前 IPC NS 中）
$ ipcs -q           // 只能看到当前 IPC NS 内的队列

1.5 UTS Namespace：主机名隔离

UTS Namespace 是最简单的 Namespace 类型之一，隔离了 hostname 和 NIS domain name。容器中的 hostname 命令返回的是容器内的主机名：

// uname() 系统调用返回的信息来自 current->nsproxy->uts_ns
struct uts_namespace {
    struct new_utsname name;
    struct user_namespace *user_ns;
    struct ucounts *ucounts;
    struct ns_common ns;
};

// 在容器内设置主机名：
unshare(CLONE_NEWUTS);
sethostname("my-container", strlen("my-container"));
$ hostname
my-container  // 容器视角
$ exit
$ hostname
ybb-server    // 宿主机视角保持不变

1.6 Time Namespace：时钟偏移隔离（Linux 5.6+）

Time Namespace 是较新的特性，允许容器看到"不同的时间"——相对于宿主机的偏移量：

// kernel/time_namespace.h
struct time_namespace {
    struct user_namespace *user_ns;
    struct ns_common ns;
    struct vdso_data *vvar_data;
    struct page *vvar_page;    // vDSO 映射页
    // 每个时间 Namespace 的时钟偏移：
    struct timespec64 wall_time_offset_from_monotonic;
    struct timespec64 wall_time_offset_from_boot;
};

// 时间 Namespace 不改变 CLOCK_MONOTONIC（保证定时器正确性）
// 影响的是 CLOCK_REALTIME/CLOCK_BOOTTIME（日历时间）
// 这对需要修改日期的场景非常有用（测试、CI）

1.7 Cgroup Namespace：cgroup 根目录虚拟化

Cgroup Namespace 让进程看到"自己的 cgroup 根目录"，使得在容器内执行 cat /proc/self/cgroup 时看到的是相对于该容器 cgroup 的路径：

// 在宿主上创建容器 cgroup：
/sys/fs/cgroup/docker/abc123/

// 没有 Cgroup Namespace 时，容器内看到：
$ cat /proc/self/cgroup
0::/docker/abc123/...

// 有了 Cgroup Namespace 后，容器内看到：
$ cat /proc/self/cgroup
0::/                 // 看似从 "/" 开始，实现虚拟化

// 实现原理：修改 task_struct 中的 cgroup_ns，在 proc 渲染路径中裁减前缀

1.8 User Namespace：特权分离的核心

User Namespace 是容器安全基石，它允许非特权用户"在 Namespace 内"拥有 root 权限，但在 Namespace 外只是普通用户：

// User Namespace 中的 UID 映射（/proc/<pid>/uid_map）：
// uid_map 格式: <ns_uid> <real_uid> <count>
// 常见配置：容器内 UID 0 (root) → 宿主 UID 100000（非特权用户）
0 100000 65536

// 这意味着：
// 容器内 "root"（UID 0）在宿主机上是 UID 100000，实际没有任何特权
// 无法修改宿主机的系统文件、无法访问宿主机/dev、无法发送宿主级别的信号

// User Namespace 对其他 Namespace 的所有权：
// 必须先创建 User Namespace，然后才能在其他 Namespace 中进行相关操作
// 这解释了为什么创建 User Namespace 不需要 CAP_SYS_ADMIN

// rootless 容器（如 rootless Docker、Podman）正是基于此实现：
$ podman run -it alpine sh
# whoami
root                       // 容器内是 root
$ cat /proc/self/uid_map
0 1000 1                   // 映射：容器 root = 宿主机 UID 1000
1 100000 65535             // 后续 UID 继续偏移

二、Control Groups：资源限额的三层模型

cgroup（控制组）限制了进程可使用的系统资源。cgroup v2 相比 v1 采用统一层级树，解决了 v1 中多级联冲突带来的复杂性。

2.1 cgroup v2 核心概念

/sys/fs/cgroup/
├── cgroup.controllers      // 当前 cgroup 可启用的控制器列表
├── cgroup.events           // populated/frozen 等事件
├── cgroup.max.depth        // 子 cgroup 最大嵌套深度
│
├── docker/                 // Docker 的子 cgroup 根
│   ├── abc123/             // 单个容器的 cgroup
│   │   ├── cgroup.procs    // 属于该 cgroup 的进程列表
│   │   ├── cpu.max         // CPU 限制：$MAX $PERIOD
│   │   ├── memory.max      // 内存硬限制（字节）
│   │   ├── memory.high     // 内存软限制（触压回收）
│   │   ├── memory.low      // 内存保护阈值
│   │   ├── io.max          // IO 带宽限制
│   │   └── pids.max        // 进程数上限
│   └── ...
├── system.slice/           // 系统服务
├── user.slice/             // 用户会话
└── ...

2.2 CPU 控制器：带宽控制与权重分配

cgroup v2 的 CPU 控制器有两种工作模式：权重模式（默认，通过 cpu.weight）和 带宽上限模式（通过 cpu.max）：

// cpu.max：每周期最多使用多少时间
// 格式：$MAX $PERIOD（单位：微秒）
// 例如 "200000 100000" = 200000us / 100000us = 200% → 2 个 CPU 核心的全额时间
echo "200000 100000" > /sys/fs/cgroup/docker/abc/cpu.max

// cpu.weight：相对权重分配（默认 100，范围 1-10000）
// 当 CPU 争用时，按权重比例分配时间片
echo "500" > /sys/fs/cgroup/docker/abc/cpu.weight  // 该容器获得 2 倍于默认的份额

// 内部原理：权重模式仍然基于 CFS（完全公平调度器）
// 每个 cgroup 维护独立的 vruntime 基准
// 高权重 cgroup 的进程拥有的 vruntime 增长较慢，因此能获得更多实际 CPU 时间

2.3 内存控制器：多层级回收策略

// cgroup v2 内存控制的三个关键阈值：
// 1. memory.min：硬保护，内核绝不回收此范围内的内存（仅用于关键守护进程）
echo "104857600" > memory.min   // 100MB 硬保护

// 2. memory.low：软保护，当全局内存紧张时尽量不回收
echo "209715200" > memory.low   // 200MB 软保护

// 3. memory.high：软上限，超过此值触发回收压力（非同步 OOM）
echo "314572800" > memory.high  // 触发非强制回收

// 4. memory.max：硬上限，触发同步 OOM Killer
echo "536870912" > memory.max   // 512MB 硬上限，超出即 OOM

// 工作流程：
// usage < high → 正常
// usage > high → 内核回收（可能短暂阻塞）
// usage > max  → cgroup OOM Killer 杀死该 cgroup 内最耗内存的进程

2.4 IO 控制器：读写带宽限速

// io.max 格式：$DEVICE $RBYTES $WBYTES $RIOPS $WIOPS
// 对指定设备设置读写带宽上限和 IO 操作数上限
// 例如：对 NVMe 设备限制读 100MB/s、写 50MB/s
echo "259:0 rbps=104857600 wbps=52428800 riops=0 wiops=0" > io.max

// io.weight 相对权重（默认 100）
// 内核底层转交给 bfq 或 mq-deadline 调度器

// io.stat：详细 IO 统计
$ cat io.stat
259:0 rbytes=1234567 wbytes=89012 rios=45 wios=23 dbytes=0 dios=0
                                          // delayed 统计（bfq 特有）

2.5 PID 控制器：防御 Fork 炸弹

// pids.max：限制 cgroup 内的进程/线程数
echo "256" > /sys/fs/cgroup/docker/abc/pids.max

// pids.current：当前使用数
// pids.peak：峰值记录（linux 6.0+）

// Fork 炸弹防御：
// 在容器内执行 :(){ :|:& };: 将失败，因为 PID 数被限制
// SIGKILL 发送给触发限制的进程（通过 cgroup OOM 路径）

三、Capabilities：root 特权的精细拆分

传统 Unix 权限模型将进程分为特权（root）和非特权两类。Linux Capabilities 将 root 的特权拆分为约 40 个独立的能力（Capability），可以细粒度地赋予或拒绝。

// include/uapi/linux/capability.h 中的关键能力
#define CAP_NET_ADMIN    12   // 网络管理（接口、路由、防火墙配置）
#define CAP_SYS_ADMIN    21   // 系统管理（挂载、Namespace 操作等）
#define CAP_SYS_PTRACE   19   // 进程追踪（gdb、strace）
#define CAP_SYS_MODULE    13  // 加载内核模块
#define CAP_SYS_RAWIO     17  // 原始 IO 端口访问
#define CAP_NET_BIND_SERVICE 10 // 绑定特权端口（<1024）
#define CAP_SETUID         7   // 修改进程 UID
#define CAP_SYS_BOOT       22  // 重启系统
#define CAP_KILL           5   // 发送信号给任意进程
// ... 共计约 40 个能力

3.1 进程能力集与容器默认 drop 规则

// 进程的能力由四个集合描述：
// Permitted：进程可被赋予的最大能力集合
// Effective：当前被激活的能力（检查时使用）
// Inheritable：保留到 execve() 子进程的能力
// Bounding set：全系统能力上限（setcap 限制）

// 容器的默认行为（Docker）：
// - 使用 capset(CAP_PCIV, ...) 为初始进程设定能力
// - 默认 drop 一众危险能力（如 CAP_SYS_ADMIN、CAP_SYS_MODULE）
// - 保留 pre-defined 安全能力集

// 验证：
$ docker run --rm alpine sh -c "cat /proc/self/status | grep Cap"
CapInh: 00000000a80425fb
CapPrm: 00000000a80425fb
CapEff: 00000000a80425fb
// 转换为可读格式：
$ capsh --decode=00000000a80425fb
0x00000000a80425fb=cap_chown,cap_dac_override,...,cap_net_bind_service,...,cap_sys_tty_config,...,cap_setuid,...

3.2 User Namespace + Capabilities：rootless 容器安全模型

rootless 容器的核心是：在容器内部，进程拥有所有 Capabilities；但在宿主机上，该进程是一个没有任何特权的普通用户。User Namespace 的 能力嵌套模型实现了这个安全边界：

// 关键规则：
// 1. 进程的 Effective Capabilities 仅在所属 User Namespace 内有效
// 2. 跨 User Namespace 的能力检查会失败（进程在"外部"不具备这些能力）
// 3. 可以为当前 User Namespace 以下所有 User Namespace 授予能力

// 实例：rootless Docker 的安全分析
// 容器内进程：Effective caps = 全部能力（在容器 User NS 内）
// 宿主机进程：UID = 100000（通常无任何 caps）
// 因此即使容器内进程是 root ++ 全 caps，也无法：
//   - 修改宿主机的设备文件
//   - 加载内核模块
//   - 设置 IP 转发（宿主机网络栈）
//   - 跟踪宿主机的其他进程

// 唯一的例外：内核漏洞可以绕过这些限制（如 CVE-2022-0185、CVE-2022-0492）

四、Seccomp-BPF：系统调用过滤

Seccomp（Secure Computing Mode）通过 BPF（Berkeley Packet Filter）程序限制容器可使用的系统调用集合。

4.1 Seccomp 工作原理

// seccomp() 系统调用的模式：
// SECCOMP_SET_MODE_STRICT：只允许 read/write/rt_sigreturn/exit
// SECCOMP_SET_MODE_FILTER：使用 BPF 程序定义过滤规则

// BPF 过滤程序的输入（struct seccomp_data）：
struct seccomp_data {
    int nr;                     // 系统调用号
    __u32 arch;                 // 架构（AUDIT_ARCH_X86_64 等）
    __u64 instruction_pointer;  // 调用时的 RIP
    __u64 args[6];              // 系统调用参数（0-5）
};

// BPF 程序的返回值：
// SECCOMP_RET_ALLOW   → 允许调用
// SECCOMP_RET_ERRNO   → 拒绝并返回指定 errno
// SECCOMP_RET_KILL_PROCESS → 杀死进程
// SECCOMP_RET_TRAP    → 发送 SIGSYS 信号
// SECCOMP_RET_LOG     → 允许但记录日志
// SECCOMP_RET_TRACE   → 通知 ptrace tracer

4.2 Docker 默认 Seccomp 配置文件

Docker 自带一个预设的 seccomp profile，默认禁止约 44 个危险系统调用（如 kexec_load、init_module、delete_module、reboot、ptrace 等）。以下为关键部分：

// docker/profiles/seccomp/default.json 框架：
{
    "defaultAction": "SCMP_ACT_ERRNO",  // 默认拒绝（EPERM）
    "archMap": [{"architecture": "SCMP_ARCH_X86_64", ...}],
    "syscalls": [
        {
            "names": [
                "accept", "bind", "brk", "clock_gettime",
                "clone", "close", "connect", "epoll_wait",
                "futex", "mmap", "nanosleep", "read", "write",
                ...  // 约 300+ 个允许的调用
            ],
            "action": "SCMP_ACT_ALLOW"
        },
        {
            "names": ["clone"],
            "action": "SCMP_ACT_ALLOW",
            "args": [
                {
                    "index": 0,    // clone_flags 参数
                    "value": 2080505856,  // CLONE_NEWNS | ... 等限制掩码
                    "op": "SCMP_CMP_MASKED_EQ"
                }
            ],
            "comment": "限制 clone 的 Namespace 创建能力"
        }
    ]
}

// 被默认禁止的高危系统调用：
// kexec_load → 加载新内核（可绕过 module_disabled）
// init_module/delete_module → 模块操作
// reboot     → 重启系统
// ptrace     → 进程追踪
// acct       → 开启/关闭进程会计
// nfsservctl → NFS 服务器操作（存在 RCE 风险）
// swapon/swapoff → 交换分区操作
// setns      → 切换 Namespace（Docker 显式禁止，防止容器通过 /proc/self/ns 进入宿主 NS）

4.3 Seccomp 的性能影响与优化

Seccomp 过滤器在内核的 syscall_trace_enter() 路径上执行，每次系统调用都会触发：

// 性能优化要点：
// 1. BPF 虚拟机在 JIT 模式下执行（与 XDP/eBPF 相同），开销很小
// 2. 系统调用号较小（x86_64 在 0-500 之间），BPF 程序可以做 O(1) 索引查找
// 3. Linux 5.12+ 支持 seccomp 缓存：相同参数的调用跳过过滤
// 4. 默认 profile 支持率：Docker 测试过 ~300 个常见系统调用，吞吐量损失 < 1%

// 如何自定义 Seccomp profile：
docker run --rm --security-opt seccomp=my-profile.json -it alpine sh

// 最小化 Seccomp 示例（仅允许 read/write/exit）：
{
    "defaultAction": "SCMP_ACT_KILL_PROCESS",
    "syscalls": [{
        "names": ["read", "write", "close", "exit_group"],
        "action": "SCMP_ACT_ALLOW"
    }]
}
// 注意：此配置下无法 fork、execve，无法分配 mmap 内存！

五、LSM：强制访问控制

LSM（Linux Security Module）是 Linux 内核的可扩展安全框架，允许在关键内核对象操作中插入安全检查钩子。常见实现包括 AppArmor、SELinux、Smack、TOMOYO。

5.1 AppArmor：基于路径的强制访问控制

AppArmor 通过对文件路径进行规则匹配来控制容器行为，Docker 内置了一个默认 AppArmor 配置文件：

// 典型 AppArmor Profile（Docker 默认）：
// /etc/apparmor.d/docker-default

#include <tunables/global>
profile docker-default flags=(attach_disconnected,mediate_deleted) {
    #include <abstractions/base>

    network,       // 允许所有网络操作
    capability,    // 允许所有能力（依赖 Capabilities 限制层）

    // 限制写操作：只允许写入用户数据目录
    deny / w,
    deny /proc/* w,  // 禁用敏感 proc 写
    deny /sys/** w,
    deny /sys/fs/** w,

    // 允许写入标准文件位置
    / r,
    /** r,
    /run/** w,
    /tmp/** w,
    ...

    // 拒绝危险操作
    deny mount,
    deny umount,
    deny pivot_root,
    deny ptrace (read, readby),
    ...
}

// 加载与验证：
$ aa-status | grep docker
// 可以确认容器进程是否在 AppArmor 限制下运行

5.2 SELinux：基于标签的强制访问控制

SELinux 为每个进程和文件系统对象分配安全上下文（type label），通过策略文件定义类型之间的操作规则：

// SELinux 安全上下文结构：
// user:role:type:sensitivity:category
// 示例：system_u:system_r:container_t:s0:c123,c456

// SELinux 在容器场景中的工作模式：
// MLS (Multi-Level Security) 模式 → 使用 sensitivity（s0）和 category (cXXX）
// MCS (Multi-Category Security) 模式 → 仅使用 category

// Docker 使用 MCS 模式：
// 每个容器分配独立的 category 标签（如 c100,c200）
// 不同容器之间 category 不重叠 → 文件隔离
// 同一容器内所有进程类型相同 → 内部通信不受限

// 策略规则示例（.te 文件）：
type container_t;              // 容器进程类型类型
type container_file_t;         // 容器文件类型
type svirt_sandbox_file_t;     // libvirt 管理的容器镜像文件类型

allow container_t container_file_t:file { create read write };
allow container_t container_file_t:dir { add_name remove_name write };
allow container_t self:tcp_socket { create connect write read };
...
// 注意 deny 更细粒度的文件类型如:
// etc_t, bin_t, lib_t, usr_t 等系统类型默认不被允许

六、容器逃逸向量与防御深度分析

容器安全的核心威胁是"容器逃逸"——攻击者从隔离的容器内突破到宿主机，获取宿主内核访问权限。以下是常见逃逸路径：

6.1 特权容器（Privileged Container）

 /proc/sys/kernel/sysrq
echo c > /proc/sysrq-trigger   // 故意触发 OOM

// 3. 向宿主 cgroup 写入 release_agent 触发 payload 执行
mkdir /tmp/cgrp && mount -t cgroup -o rdma cgroup /tmp/cgrp
echo 1 > /tmp/cgrp/x/notify_on_release
host_path=$(sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab)
echo "$host_path/cmd" > /tmp/cgrp/release_agent

// 威胁等级：极高（通常意味着完全主机控制权）
// 防御：永远不使用 --privileged，使用细粒度 caps

6.2 危险的 Capabilities 组合

CVE-2016-5195 (Dirty COW)   → 写只读内存映射 → 覆盖 /etc/passwd 或 SUID 二进制
CVE-2017-16995 (eBPF)       → eBPF 验证器缺陷 → 任意内核内存读写 → 提权
CVE-2022-0185               → fsconfig 溢出 → 覆盖相邻 object → 逃逸
CVE-2022-0492              → cgroup release_agent 容器间逃逸 → 完整主机控制权
CVE-2022-0847 (Dirty Pipe) → 只读文件写入 → 覆盖关键文件 → root 获取
CVE-2024-1086              → nf_tables UAF → 本地提权 → 逃逸容器
CVE-2024-26809             → Netlink 整数下溢 → 内核利用

防御策略包括：及时更新内核、减小 syscall 面（seccomp profile）、使用 gVisor/Kata Containers 等多层隔离方案。

七、gVisor 与 Kata：超越软隔离的安全容器

当"共享内核"的容器架构无法满足安全需求时，需要使用 安全容器（Secure Container）方案。

7.1 gVisor：用户态内核重构

gVisor（由 Google 开发）在用户态实现了一个完整的 Linux 内核（Sentry），容器内的系统调用被拦截并模拟执行，避免了直接调用宿主内核：

// gVisor 架构：
┌─────────────────┐
│  Container App  │  调用 read/write/socket 等
└───────┬─────────┘
        │ (syscall)
┌───────┴─────────┐
│  gVisor Sentry  │  用户态内核：重新实现 系统调用
└───────┬─────────┘
        │ (少数真正 syscall)
┌───────┴─────────┐
│  Host Kernel    │  宿主内核几乎不被直接调用
└─────────────────┘

// 优势：
// - 实现了系统调用的"虚拟化"（如 mprotect/proc 等受限）
// - 攻击者成功逃逸的是 Sentry 进程（用户态），不是宿主内核
// - 性能开销较大（约 20-60% 的吞吐损失）

// 劣势：
// - 系统调用不完整（不支持所有 syscall）
// - 内存占用高于普通容器
// - fork/exec 性能受限

7.2 Kata Containers：轻量级虚拟机

Kata Containers 将每个容器运行在专用的轻量级虚拟机中，通过 virtio-vsock 或 virtio-fs 与宿主通信：

// Kata 架构：
┌──────────────────────────────────────────┐
│ Host Kernel                              │
│  ┌─────────────────────────────────────┐ │
│  │ Kata VM (Guest Kernel)              │ │
│  │  ┌───────────────────────────────┐  │ │
│  │  │  Guest Userspace              │  │ │
│  │  │  ┌─────────────┐              │  │ │
│  │  │  │  Container  │ (应用运行环境)  │  │ │
│  │  │  └─────────────┘              │  │ │
│  │  └───────────────────────────────┘  │ │
│  └─────────────────────────────────────┘ │
└──────────────────────────────────────────┘

// 关键技术：
// - guest kernel 仅编译必要的驱动（去掉了不必要的 syscall）
// - 内核裁剪后体积约 5MB，启动时间 ~100ms
// - 内存占用约 100-200MB（轻量级 QEMU 或 Cloud Hypervisor）
// - 通过 TTRPM（Trusted Platform Module）提供硬件信任根

// 优势：
// - 最严格的隔离（VM 边界）
// - 支持机密计算（AMD SEV / Intel TDX）
// - 兼容标准容器镜像

// 劣势：
// - 内存开销较高（每个容器额外 100MB+）
// - IO 性能损失（virtio 驱动）
// - 启动时间开销（~200ms）

八、生产环境最佳实践总结

1. 基础隔离组合
   ✓ 全 Namespace 隔离（PID、Net、Mnt、IPC、UTS、Time、User、Cgroup）
   ✓ cgroup v2 限制 CPU/IO/内存/PID
   ✓ 默认 drop 所有 Capabilities，仅 add 必要的

2. 调用限制
   ✓ Seccomp Profile 过滤危险 syscall
   ✓ LSM（AppArmor/SELinux）策略限制文件访问
   ✓ Bounding set 限制

3. 网络安全
   ✓ 不要 --net=host，使用独立 Net NS + veth pair
   ✓ 自定义 iptables 规则限制容器出站流量
   ✓ 避免 privileged 网络工具在容器中运行

4. 运行原则
   ✓ 非 root 用户使用容器（rootless 模式）
   ✓ 非特权 Linux capabilities（CAP_SETUID 等关键 cap 不赋予）
   ✓ read-only 根文件系统（docker run --read-only）
   ✓ 永不使用 --privileged
   ✓ 及时备份容器、设置资源限额

5. 监控与审计
   ✓ Auditd 检测异常 syscall（读/写特权设备、setuid 等）
   ✓ Falco 监控容器行为（异常文件访问、网络连接）
   ✓ 核心区审计（异常 outbound 连接、新命名空间创建）
   ✓ 镜像安全扫描（Clair、Trivy、Grype）

6. 进阶防御
   ✓ 安全容器（gVisor for 中等安全需求，Kata for 高安全需求）
   ■ 机密计算（AMD SEV-SNP / Intel TDX 硬件加密）
   ✓ RuntimeClass 按需选择容器运行时
   ✓ Pod Security Standards (restricted profile)

结语

Linux 容器的隔离不是单一技术，而是 Namespaces（视图隔离）+ cgroups（资源限制）+ Capabilities（权限拆分）+ Seccomp（调用限制）+ LSM（访问控制） 五个维度的纵深防御体系。理解每一层机制的原理、假设和局限性，是评估容器安全状态的必要前提。在共享内核容器依然主流的今天，gVisor 和 Kata 等安全容器方案为硬隔离需求提供了可行路径。安全永远不是一个开关，而是一个持续评估、分层部署和升级维护的过程。