Linux容器逃逸风险默认配置下高于KVM，因容器依赖软件隔离而KVM有硬件级隔离；需严格配置capabilities、user namespace、seccomp、SELinux等多层防护。
Linux 容器逃逸风险比 KVM 更高？
不是绝对更高，但默认配置下更易触发——docker 或 podman 运行时若未禁用特权、未限制 capabilities、未挂载只读 /proc 和 /sys，一次 nsenter -t 1 -m /bin/sh 就可能跳出容器。KVM 虚拟机底层有硬件级隔离，逃逸需利用内核模块漏洞或 QEMU 侧信道，门槛明显更高。
实操建议：
- 容器启动时强制加
--cap-drop=ALL --security-opt=no-new-privileges - 避免使用
--privileged，真需要设备访问就用--device显式授权 - 在
/etc/docker/daemon.json中设"default-ulimits": {"nofile": {"Hard": 65536, "Soft": 65536}}，防 ulimit 绕过资源限制 - 运行时检查是否启用 user namespace：执行
cat /proc/1/status | grep Uid，若看到非 0 的 Uid 映射，说明已启用，这是基础隔离项
seccomp-bpf 规则写错反而放大攻击面
很多人直接套用 Docker 官方 default.json，但没注意它放行了 clone、unshare、mount 等系统调用——这些正是 namespace 逃逸和 rootfs 覆盖的关键入口。规则不是越宽松越安全，而是要按 workload 最小权限裁剪。
实操建议：
- 用
strace -f -e trace=clone,mount,unshare,pivot_root,openat先跑一遍业务进程，确认哪些调用真被用到 - 禁止
mount时，必须同时禁用MS_BIND和MS_REC标志，否则仍可 bind-mount 宿主机路径 - 不要在 seccomp 规则里留
"action": "SCMP_ACT_TRACE"上线环境，这会暴露系统调用序列，辅助攻击者做指纹识别 - 验证规则生效：容器内执行
cat /proc/1/status | grep Seccomp，值为2表示 enforce 模式已启用
systemd-nspawn 的 --private-users 没生效？
常见原因是宿主机内核未开启 user namespace 支持，或 systemd 版本太低（systemd-nspawn --private-users 启动后查 /proc/1/uid_map 为空，说明 fallback 到了非用户命名空间模式，隔离形同虚设。
实操建议：
- 先确认内核支持：
zgrep CONFIG_USER_NS /proc/config.gz或cat /boot/config-$(uname -r) | grep CONFIG_USER_NS，输出应为y或m - 检查
/proc/sys/user/max_user_namespaces是否 > 0；若为 0，临时开：echo 10000 > /proc/sys/user/max_user_namespaces - 启动时加
--private-users-chown，否则容器内文件属主不会自动映射到子 UID 范围 - 验证方式：进容器后执行
id，输出应显示类似uid=0(root) gid=0(root) groups=0(root),65534(nogroup)，且cat /proc/1/uid_map有非空映射行
SELinux 策略中 container_t 和 svirt_lxc_net_t 的区别
二者都用于容器，但 container_t 是 docker 默认上下文，策略宽松，允许访问 docker_var_lib_t、container_file_t；而 svirt_lxc_net_t 是 libvirt-LXC 使用的类型，强制绑定 svirt_image_t 和 svirt_tmpfs_t，网络相关操作受 svirt_lxc_net_port_t 约束。混用会导致 AVC denied 频发，甚至服务起不来。
实操建议：
- docker 不要手动改容器进程上下文为
svirt_lxc_net_t，它不认docker_exec_t的入口点 - libvirt-LXC 若需共享存储，得显式声明
<seclabel type="dynamic" model="selinux" relabel="yes"></seclabel>，否则镜像层无法自动打标 - 调试时用
ausearch -m avc -ts recent | audit2why，别只看setenforce 0了事 - 自定义策略要加
container_runtime_domain(container_t)宏，否则docker exec里的 shell 进程无法继承上下文
真正难的不是配齐所有开关，而是理解每个隔离层失效时的 fallback 行为——比如 cgroups v1 下 memory.limit_in_bytes 写错单位，OOM killer 会直接杀宿主机进程；又比如 seccomp + user namespace + SELinux 三层全开，但某个服务仍用 root:root 启动，那前面所有策略都白搭。
