seccomp限制高危系统调用须以白名单为核心：默认拒绝所有（default_action设为scmp_act_errno或scmp_act_kill），仅放行openat、read、statx等运行必需调用，并显式拦截ptrace、chroot等无业务用途的高危项，同时严格遵循json三要素（default_action、architectures、syscalls）及绝对路径加载规范。
直接用 Seccomp 限制容器内高危系统调用，不是简单删掉几个“看着危险”的名字，而是以白名单为前提，先保运行、再控风险——默认拒绝所有，只放行真实需要的调用，同时对明确无业务用途的高危项做显式拦截。
必须写对的 JSON 结构三要素
Seccomp 配置是纯 JSON，Docker daemon 加载时逐字段校验，错一个就启动失败：
- default_action：必须是小写下划线写法，值为 "SCMP_ACT_ERRNO"（返回错误）或 "SCMP_ACT_KILL"（终止进程），不能写成 defaultAction 或 DefaultAction
- architectures：必须显式声明宿主机架构，如 ；ARM 节点还要加 ，漏掉会报 “no matching architecture”
- syscalls：必须是复数形式的数组，每个元素含 names（字符串数组，哪怕只禁一个也要写成 ）和 action（如 ）
校验建议：用 jq -e '.default_action, .architectures, .syscalls' /etc/docker/seccomp.json >/dev/null，非零退出即说明结构不合法。
基础调用不能禁，否则容器直接瘫痪
openat、read、statx 这类调用不是“可选”，而是绝大多数程序启动和运行的底层依赖。禁掉它们，连 ls、ps 都失败，Go 程序读不了 /proc/self/exe 就 panic，Node.js 事件循环卡在 epoll_wait 就 hang 住。
最小可用集合通常包括：
- 文件操作：openat、read、close、statx、fstat
- 内存管理：mmap、mprotect、brk
- 运行时支撑：clone（Go 启动 goroutine）、epoll_wait / epoll_ctl（Node.js/Go 事件循环）、getrandom（安全随机数）
别靠经验猜——用 strace -f -e trace=raw_syscall -p $(pidof your-app) 抓真实调用流，再筛出高频、非特权、必需项。
高危调用要主动覆盖，不依赖默认策略
Docker 默认 profile 已禁约 44 个调用，但生产环境不能指望它兜底。以下调用在 Web 服务等常规场景中几乎无正当用途，应显式拦截：
- ptrace：防止调试注入与内存篡改，建议设 （返回 EPERM，便于日志捕获）
- mount、umount2：阻断挂载逃逸路径，可用 （一旦触发基本就是攻击尝试）
- chroot、setns、unshare：关闭命名空间操控能力
- reboot、swapon、swapoff：避免影响宿主机资源管理
- capset：提权关键入口，必须禁，推荐 避免因能力检查失败导致程序异常退出
路径与权限必须由 daemon 视角验证
Docker daemon 以 root 身份运行，它看不到你的当前目录、~ 符号或相对路径：
- 配置文件必须存为绝对路径，如 /etc/docker/seccomp.json，不能用 ./profile.json 或 ~/seccomp.json
- 确保 daemon 用户（通常是 root）可读：sudo chmod 644 /etc/docker/seccomp.json
- 运行容器时指定完整路径：docker run --security-opt seccomp=/etc/docker/seccomp.json ...
- 不要在 Dockerfile 中 COPY 进镜像——Seccomp 是 runtime 行为，只在 docker run 时加载
常见报错 "open profile.json: no such file"，90% 都源于路径没走对。
