直接回答：capabilities 把 root 的全能拆成约 40 个细粒度权限（CAP_NET_BIND_SERVICE 绑低端口、CAP_SYS_ADMIN 近乎万能、CAP_CHOWN 改属主），让进程只拿所需特权而非 root；seccomp 是系统调用过滤器，用 BPF 规则决定进程能调哪些 syscall（默认容器 profile 禁掉约 44 个高危调用如 kexec_load、init_module）。一个管“特权粒度”，一个管“接口面收缩”，方向互补。

展开解析：容器里的默认姿态：Docker/K8s 默认只给十几个温和 capabilities（NET_RAW 常被忽略——它允许构造原始报文，ping 可用但也利于内网探测，多租户环境建议 drop），seccomp 用默认 RuntimeDefault profile。加固实践：SecurityContext 里 drop ALL 再按需 add（Web 服务通常一个都不用加）；readOnlyRootFilesystem、runAsNonRoot、no-new-privileges 四件套配合；需要特权的运维容器用短期授权而非常驻 NET_ADMIN。排障套路：进程报 EPERM 先看是不是 capability 被 drop（capsh --print 对比），seccomp 拦截通常是返回 EPERM 而非 SIGSYS（取决于 action），audit 日志与 /proc/self/status 的 Seccomp 字段可确认。认知要点：CAP_SYS_ADMIN 被称为“新 root”，挂载、namespace 操作一大把，授予它基本等于放弃隔离；seccomp 自定义 profile 的维护成本高（应用升级引入新 syscall 就挂），灰度用 SCMP_ACT_LOG 先观测再收紧。

追问方向：ambient capabilities 与文件 capabilities 的区别？user namespace 如何进一步削弱 capability 的威力？

（约 480 字）