在 Docker 容器中，应用突然出现“Operation not permitted”“Permission denied”或返回 EPERM，并不一定是文件权限、用户身份或 Linux Capability 配置错误，也可能是 Seccomp 拒绝了某个系统调用。Seccomp 是 Linux 内核提供的系统调用过滤机制，可在调用进入内核处理逻辑前执行拦截，是容器最小权限防护的重要组成部分。本文将从配置、验证到故障定位，介绍一套可落地的排查方法。🔐
一、理解 Docker Seccomp 的工作方式
Docker 在 Linux 环境中默认启用 Seccomp 配置文件。其基本思路是：以允许列表为基础，对常用系统调用放行，对风险较高或容器通常不需要的调用返回错误。默认策略通常使用 SCMP_ACT_ERRNO，因此应用看到的往往只是 EPERM，而不会直接提示“Seccomp 已拒绝”。
根据 Docker Seccomp 官方文档，默认配置兼顾安全性与应用兼容性，并会限制部分可能影响宿主机内核、时间、模块、密钥环或调试能力的系统调用。一般不建议为了省事直接关闭默认配置，而应先确认应用究竟需要哪些调用。
二、确认宿主机与容器是否启用 Seccomp
首先检查内核是否支持 Seccomp：
grep CONFIG_SECCOMP= /boot/config-$(uname -r)
正常情况下应看到 CONFIG_SECCOMP=y。某些发行版没有保存当前内核配置文件，也可以检查 /proc/config.gz，或查询发行版提供的内核包信息。
随后查看容器状态：
docker inspect 容器名 --format '{{json .HostConfig.SecurityOpt}}'
docker exec 容器名 grep Seccomp /proc/1/status
在 /proc/进程号/status 中，Seccomp 值为 2 通常表示启用了过滤模式；值为 0 表示未启用。还应检查容器启动参数中是否存在 seccomp=unconfined，它会关闭该容器的 Seccomp 过滤。⚠️
三、应用自定义 Seccomp 配置
自定义策略通常采用 JSON 文件描述，包括默认动作、支持的体系结构、系统调用名称、规则动作和参数条件。推荐从与当前 Docker Engine 版本匹配的默认配置出发，仅做必要调整，而不是从一个过度宽松的空白策略开始。
启动容器时可通过以下方式加载配置：
docker run --rm --security-opt seccomp=/path/to/profile.json 镜像名
相对路径由 Docker CLI 按执行命令时的工作目录解析。当客户端与 Docker daemon 位于不同主机时，配置文件需要位于客户端可读取的位置，因为 CLI 会读取文件并将内容发送给 daemon。相关行为可参考 官方配置说明。
在 Compose 中，可以在服务的 security_opt 下设置 seccomp:profile.json。修改策略后应重新创建容器，仅执行 restart 不一定会应用新的安全选项。
四、系统调用被拒绝时的排查流程
1. 记录完整错误场景
先确认失败发生在启动阶段还是运行阶段，并记录镜像版本、Docker Engine 版本、宿主机内核、CPU 架构、容器用户、Capabilities 与安全选项。同一个系统调用可能同时受到 Seccomp、Capabilities、AppArmor、SELinux 或普通文件权限约束，因此不能仅凭 EPERM 就下结论。
2. 使用 strace 定位失败调用
如果镜像中具备 strace，可跟踪主进程及其子进程：
strace -f -o /tmp/trace.log 应用启动命令
grep -E 'EPERM|EACCES' /tmp/trace.log
重点关注返回 -1 EPERM 的系统调用，以及失败前后的参数和子进程行为。仅看到某个调用失败并不代表它一定被 Seccomp 拦截，还要结合内核审计记录进一步判断。🧭
3. 检查内核与审计日志
在宿主机上检索 Seccomp 相关记录：
journalctl -k | grep -i seccomp
dmesg | grep -i seccomp
ausearch -m SECCOMP
若系统启用了 auditd，日志中可能包含进程名、架构、系统调用编号与动作结果。系统调用编号会随 CPU 架构变化，可通过 ausearch、ausyscall 等工具转换，避免把 x86_64 编号直接套用到 arm64 环境。
4. 用 unconfined 做对照实验
在隔离的测试环境中，可临时关闭 Seccomp 后复现：
docker run --rm --security-opt seccomp=unconfined 镜像名
如果关闭后问题消失，说明 Seccomp 是重点嫌疑对象；如果问题仍然存在，应继续检查 Capability、AppArmor、SELinux、挂载选项和容器用户权限。不要将 unconfined 作为生产环境的长期修复方案，因为它会显著扩大容器可访问的内核接口范围。
五、安全修改策略的正确方法
- 只放行必要调用：根据可重复的测试结果添加规则，不要一次允许一组不相关的高风险系统调用。
- 同步检查 Capability：某些调用即使通过 Seccomp，也仍需要对应的 Linux Capability；反之，增加 Capability 不会自动绕过 Seccomp。
- 区分运行阶段：初始化任务、健康检查、主程序和调试工具所需的调用可能不同，应覆盖完整生命周期。
- 考虑架构差异：在 amd64 与 arm64 上分别验证，避免因调用名称、参数或 libc 实现差异导致策略失效。
- 保留可回滚版本：将配置文件纳入版本控制，记录修改原因、应用范围与测试结果。
六、上线前的验证清单
- 确认策略文件能够被 Docker 正常解析，容器可稳定启动。
- 执行核心业务、异常分支、健康检查、优雅退出和升级流程。
- 核对审计日志中是否仍有预期之外的 Seccomp 拒绝。
- 确认未使用 privileged 或 seccomp=unconfined 掩盖问题。
- 验证自定义策略与当前 Docker、libseccomp、内核及硬件架构兼容。
- 在测试环境模拟回滚，确保错误策略不会造成持续不可用。
总结
排查 Docker Seccomp 问题的关键，是把“权限不足”逐步缩小为“哪个进程、在哪种架构下、以什么参数调用了哪个系统调用，以及由哪一层安全机制拒绝”。推荐遵循复现错误 → strace 定位 → 审计日志验证 → unconfined 对照 → 最小化放行 → 回归测试的顺序。合理使用 Seccomp 不仅能解决兼容性问题，还能减少容器被利用后直接攻击宿主机内核的机会，让安全配置真正做到可解释、可维护、可审计。✅
