要封锁容器提权路径，核心是用AppArmor控制资源访问、Seccomp掐断危险系统调用；两者配合可使获root权限的进程也无法提权或逃逸。
要封锁容器提权路径，核心不是“加功能”，而是用 LSM（Linux Security Modules）做精准拦截——AppArmor 控制进程能访问哪些文件、网络和资源，Seccomp 直接掐断危险系统调用。两者配合，能让即使获得 root 权限的容器进程也动弹不得。
明确提权路径并针对性封堵
攻击者常通过以下路径尝试提权，每条都对应可配置的 LSM 拦截点：
- 挂载宿主机目录或设备：利用 mount/umount 系统调用逃逸。Seccomp 可直接禁用这两个调用；AppArmor 配置中禁止对 /proc/sys、/dev、/sys/fs/cgroup 等敏感路径的写入和挂载权限。
-
调试注入与进程劫持：ptrace、process_vm_readv、process_vm_writev 是常见逃逸入口。Seccomp 默认已禁用 ptrace，建议在自定义策略中显式设为
"action": "SCMP_ACT_KILL_PROCESS"，让调用直接终止整个进程。 -
能力提升操作：capset、setuid、setgid、chown 等调用可用于提权。AppArmor profile 中应限制
capability行为，例如不声明capability setuid,，同时 Seccomp 策略中将 capset 列入黑名单。 - 内核模块加载：init_module、delete_module 调用可加载恶意驱动。这些调用在 Docker 默认 seccomp 配置中已被禁用，无需额外操作，但自定义策略中务必保留该限制。
AppArmor 配置要点：拒绝默认，最小授权
Docker 默认使用 docker-default profile，它已屏蔽多数高危行为，但生产环境需进一步收紧：
- 避免使用
--security-opt apparmor=unconfined，哪怕临时调试也不推荐； - 自定义 profile 时，以 deny 规则为主，例如：
deny /proc/sys/** wklx,（禁止所有对 /proc/sys 的读写执行）deny /dev/** mrwlkx,（禁止访问大部分设备节点）； - 不启用
change_profile或change_hat，防止容器内切换到更宽松策略； - profile 名称必须与
--security-opt apparmor=xxx中一致，且需用apparmor_parser -r加载生效。
Seccomp 策略编写：白名单 + 强动作控制
不要沿用默认配置就止步，而应基于应用真实行为构建最小白名单：
- 从 Docker 官方默认 JSON（default.json）出发，删除未使用的允许项；
- 设置
"defaultAction": "SCMP_ACT_ERRNO"，确保未列明调用一律返回 EPERM； - 对高危调用如
clone（带 CLONE_NEWUSER）、mount、keyctl，使用"SCMP_ACT_KILL_PROCESS"动作，比简单返回错误更彻底； - 若容器需绑定 80 端口，只允许
bind和socket，禁用socketcall（旧接口，风险高）； - 验证方式：进容器运行
strace -e trace=mount,ptrace,clone sleep 1，确认被拦截并显示EPERM或进程退出。
运行时启用与验证闭环
配置不是一次写完就结束，关键在启动时生效并持续验证：
- Docker 启动命令示例：
docker run --rm \<br> --security-opt apparmor=my-restrictive-profile \<br> --security-opt seccomp=/etc/docker/seccomp/restrictive.json \<br> -it alpine sh
- 检查容器是否真正加载了策略：
进容器执行cat /proc/1/status | grep -i seccomp，值为2表示 seccomp 已启用；
执行aa-status --enabled确认 AppArmor 处于启用状态，并查看当前进程 profile 名称； - 结合
auditctl或 Falco 抓取被拦截的系统调用事件，形成日志反馈闭环，及时发现策略过严或遗漏。
