我是怎么理解 eBPF、AppArmor 和 Seccomp 的？

我是怎么理解 eBPF、AppArmor 和 Seccomp 的先说结论不要把 eBPF 当成 AppArmor也不要把 Seccomp 当成完整的沙箱。我的理解是Seccomp 缩小系统调用面AppArmor 限制文件和能力eBPF 负责把运行时发生的事情记录下来。写在前面这不是一篇“看完就会逃逸”的文章我最开始接触这几个东西是因为一次很普通的容器故障服务在宿主机上运行正常放进容器后却突然报Permission denied。当时第一反应是把权限放开结果服务是起来了但自己也说不清到底放开了什么。后来我才慢慢把这件事拆开先看进程调用了什么再看 syscall 有没有被拦最后看文件、能力和 profile。这个过程里eBPF、Seccomp 和 AppArmor 才从几个容易混在一起的名词变成了三个不同位置的工具。目录一、为什么要同时理解这三项技术二、eBPF在内核事件上构建可观测性与安全能力三、AppArmor以配置文件约束进程行为四、Seccomp用系统调用过滤缩小内核攻击面五、三者放在一起分层防御模型六、容器安全基线示例七、总结参考资料一、为什么要同时理解这三项技术容器共享宿主机内核。容器里的进程虽然拥有独立的文件系统、网络命名空间和进程视图但最终仍然会通过系统调用进入同一个 Linux 内核。一次典型的攻击链可能是应用依赖存在漏洞攻击者获得容器内代码执行能力进程尝试读取敏感文件、访问宿主机设备或调用高风险系统调用攻击者继续利用内核或配置错误扩大权限运行时没有审计与告警直到数据泄露才被发现。三项技术分别解决不同问题技术核心问题典型能力不能替代什么eBPF发生了什么是否异常低侵入观测、审计、网络处理、运行时检测不是默认的访问控制策略也不是自动沙箱AppArmor进程可以访问哪些对象文件路径、能力、网络、信号等强制访问控制不能完整限制所有系统调用Seccomp进程可以调用哪些系统调用允许/拒绝 syscall过滤参数降低内核攻击面不能表达复杂的文件路径权限一句话记忆Seccomp 管入口AppArmor 管资源eBPF 管观测和动态策略。二、eBPF在内核事件上构建可观测性与安全能力2.1 eBPF 到底是什么eBPFextended Berkeley Packet Filter是一套运行在 Linux 内核中的安全、可验证、事件驱动的程序执行机制。它允许开发者把小型程序加载到内核中的特定挂载点在不修改内核源码、通常也不需要重启内核的情况下观测或处理系统行为。常见挂载点包括Tracepoint内核预定义的稳定事件例如进程执行、系统调用、网络事件kprobe/kretprobe动态探测内核函数的进入和返回Uprobe/uretprobe探测用户态程序或共享库函数LSM BPF参与 Linux Security Module 决策TC/XDP在网络协议栈较早阶段处理数据包cgroup hooks围绕容器或 cgroup 进行网络、套接字和设备相关控制。一个 eBPF 程序通常由以下部分组成用户态加载器 │ 通过 bpf() 系统调用加载 ▼ 内核 verifier验证器 │ 检查边界、循环、内存访问和可达性 ▼ eBPF 程序 map ring buffer │ ├── 采集内核事件 ├── 更新状态 └── 将事件送回用户态2.2 eBPF 的安全性来自哪里eBPF 并不是“任意内核代码注入”。程序加载前通常会经过 verifier 检查重点包括是否存在越界内存访问指针类型和生命周期是否正确是否可能执行不可控的无限循环是否调用了当前程序类型不允许的 helper是否满足权限和内核配置要求。但这不意味着 eBPF 没有风险。生产环境仍然要关注谁拥有加载 eBPF 程序所需的权限内核版本、BTF、helper 能力是否一致运行时探针是否引入过高开销探针采集的数据是否包含敏感信息容器是否被授予了不必要的CAP_BPF、CAP_SYS_ADMIN等能力。2.3 用 bpftrace 观察进程执行下面的示例用于观察系统中执行过的程序。它适合在测试环境快速定位“谁启动了什么”不建议直接作为生产审计方案。sudobpftrace-e tracepoint:syscalls:sys_enter_execve { printf(pid%d comm%s file%s\\n, pid, comm, str(args-filename)); } 在容器环境中可以进一步结合 PID、cgroup、容器元数据进行归属判断。实际落地时建议使用成熟工具或自研 agent统一处理事件去重、采样、脱敏和告警。我自己排查问题时一般先从execve这种事件开始看。因为“容器里到底启动了什么”往往比一上来研究一大堆 profile 更容易得到线索。比如服务偷偷启动了 shell、健康检查脚本路径不对通常几分钟就能看出来。2.4 eBPF 适合做什么进程启动、文件访问、网络连接、提权行为审计容器运行时检测例如在容器中执行 shell、写入敏感路径网络可观测性和高性能数据面处理性能分析例如 CPU、I/O、锁竞争和调度延迟与 LSM、cgroup、网络 hook 结合构建动态安全策略。2.5 eBPF 的边界eBPF 首先是一种内核扩展和事件处理机制而不是“一键安全开关”。只部署观测程序并不会自动阻止危险行为事件采集不等于完整审计丢事件、采样和权限都会影响结论直接使用 kprobe 依赖内核实现细节跨版本稳定性不如 tracepoint复杂策略需要清晰的失败模式否则可能出现误杀或性能问题eBPF 程序本身也必须纳入版本管理、权限管理和发布审计。三、AppArmor以配置文件约束进程行为3.1 AppArmor 的基本模型AppArmor 是 Linux Security ModuleLSM之一采用路径为中心的强制访问控制模型。管理员为一个程序定义 profile指定它可以读取、写入、执行哪些路径以及允许使用哪些能力、网络类型和信号。与传统 Unix 权限相比AppArmor 的关键差异是Unix 权限回答“文件所有者和权限位是否允许”AppArmor 进一步回答“这个进程即使拥有 Unix 权限是否仍被 profile 允许”。常见 profile 规则/usr/bin/my-service { # 只读配置 /etc/my-service/** r, # 允许写入运行时目录 /var/lib/my-service/** rwk, # 允许执行指定程序 /usr/bin/helper ix, # 拒绝访问密钥目录 deny /root/.ssh/** r, # 允许建立网络连接 network inet stream, }权限字符常见含义权限含义r读取w写入k文件锁m映射到内存并执行x执行具体继承方式由规则决定ix执行后继承当前 profilepx执行后切换到指定 profile一个我觉得比较实用的排查顺序遇到权限问题时我现在基本不再直接给容器加privileged。先确认实际行为再一点点加规则最后用完整链路回归验证。这样慢一点但出了问题还能解释也方便后续收紧权限。3.2 Complain 模式与 Enforce 模式开发和上线前建议采用两阶段Complain记录违反规则的行为但不阻止根据审计日志补充最小权限规则Enforce正式阻止未授权行为持续观察误报和业务变更。# 查看 profile 状态sudoaa-status# 将 profile 切换为观察模式sudoaa-complain /etc/apparmor.d/usr.sbin.my-service# 将 profile 切换为强制模式sudoaa-enforce /etc/apparmor.d/usr.sbin.my-service3.3 Docker 中使用 AppArmor宿主机已加载 profile 后可以在启动容器时指定dockerrun--rm\--security-optapparmormy-container-profile\--read-only\--cap-dropALL\nginx:stableKubernetes 中可以通过运行时类相关配置或安全上下文使用 AppArmor。不同 Kubernetes 版本和容器运行时的配置方式存在差异生产环境应以集群版本文档和节点实际 profile 状态为准。3.4 AppArmor 的优势与局限优势规则以路径为中心对应用运维人员相对直观可以精细限制配置、密钥、设备和执行文件能与容器运行时结合形成应用级隔离不需要改造应用代码。局限路径模型不等于文件对象模型硬链接、挂载和命名空间场景需要谨慎验证profile 过于宽松时攻击者仍可能利用允许路径profile 过于严格时容易因业务升级产生启动失败AppArmor 不是系统调用过滤器不能替代 Seccomp宿主机必须启用并正确配置 AppArmor容器内写 profile 并不会自动获得宿主机强制效果。四、Seccomp用系统调用过滤缩小内核攻击面4.1 为什么要限制系统调用Linux 用户态程序通过系统调用使用内核能力。一个普通 Web 服务可能只需要文件、网络、内存和线程相关系统调用但如果它同时拥有挂载、加载内核模块、调试任意进程等能力漏洞被利用后的攻击面会显著扩大。Seccompsecure computing允许进程设置系统调用过滤器。当进程发起 syscall 时过滤器可以根据系统调用编号架构syscall 参数当前过滤器动作决定允许、拒绝、返回错误、触发审计或终止进程。4.2 Seccomp 的两种主要模式Strict mode只允许极少数系统调用适用范围非常有限Filter mode通过 BPF 过滤器定义更灵活的规则容器场景主要使用这一模式。Seccomp 使用的是经典 BPF 过滤逻辑和 eBPF 有关联但不是同一个东西。不要因为都出现 BPF 就把两者当成同一套技术Seccomp 的目标是 syscall 过滤eBPF 的目标是可验证的内核程序与事件处理生态。4.3 Docker 使用自定义 Seccomp profile我第一次写 Seccomp 规则时犯过一个很典型的错误看到某个 syscall 可疑就直接拒绝结果服务启动阶段就挂了。后来改成先用默认 profile 跑完整测试再针对确实不需要的调用做限制排障成本低很多。下面是一个简化示例表示拒绝mount系统调用。完整 profile 还需要根据应用实际调用情况设计不建议直接拿示例当生产白名单。{defaultAction:SCMP_ACT_ALLOW,syscalls:[{names:[mount],action:SCMP_ACT_ERRNO,errnoRet:1}]}启动容器dockerrun--rm\--security-optseccomp./seccomp.json\nginx:stable生产环境更推荐从“默认拒绝、按需放行”的思路设计但必须先通过测试或运行时观测收集应用调用集否则很容易误伤正常功能。4.4 Seccomp 与 capability 的关系两者控制层次不同Capability控制进程是否拥有某类特权Seccomp控制进程能否调用某些系统调用某个 syscall 被允许也不代表它一定有权限成功执行某个 capability 被删除也不代表相关 syscall 不会被调用。因此安全基线通常是同时做dockerrun--rm\--cap-dropALL\--security-opt no-new-privileges:true\--security-optseccomp./seccomp.json\image:tag4.5 Seccomp 的局限它看见的是 syscall不擅长表达“只能访问某个目录”syscall 参数过滤复杂架构差异和兼容性需要测试某些高层行为会通过多个 syscall 完成只过滤一个 syscall 可能不够容器运行时默认 profile 不是万能的不能替代应用自身的最小权限设计过滤规则错误可能导致应用启动失败甚至让故障排查变得困难。五、三者放在一起分层防御模型一个更准确的关系图如下应用进程 │ ├── 发起系统调用 ── Seccomp这个 syscall 能不能进内核 │ ├── 访问文件/网络/能力 ── AppArmor这个资源是否允许访问 │ └── 行为产生事件 ── eBPF谁做了什么是否需要告警或处置推荐组合场景SeccompAppArmoreBPF互联网暴露的 Web 服务必选推荐推荐构建任务/CI Runner必选推荐推荐多租户平台严格配置严格配置强烈推荐低风险内部工具使用默认 profile按需按需需要高性能网络处理保持 syscall 最小化保护宿主资源可用于 XDP/TC一个现实的安全闭环用 eBPF 或审计工具收集应用真实行为根据行为生成初始 syscall 和文件访问清单用 Seccomp 删除不需要的内核入口用 AppArmor 限制配置、密钥、设备和执行路径再用 eBPF 持续检测 profile 绕过、异常执行和横向行为将事件接入日志、告警和应急响应系统。六、容器安全基线示例下面的命令展示一组常见的加固参数。参数是否适用要以应用测试结果为准dockerrun--rm\--read-only\--tmpfs/tmp:rw,noexec,nosuid,size64m\--cap-dropALL\--security-opt no-new-privileges:true\--security-optseccomp./seccomp.json\--security-optapparmormy-container-profile\--pids-limit256\--memory512m\--cpus1\my-service:1.0检查重点是否真的需要写入根文件系统是否真的需要某个 capability是否存在必须使用的 setuid/setgid 程序是否需要调试、挂载、加载模块或访问设备profile 被拒绝后应用是否能输出可定位的错误日志规则是否经过升级、回滚和灾备演练。在 Kubernetes 中还应结合allowPrivilegeEscalation: falsereadOnlyRootFilesystem: truerunAsNonRoot: true删除不必要的 Linux capabilitiesPod Security Standards节点级 AppArmor/Seccomp 配置运行时检测与审计平台。七、总结Seccomp通过过滤系统调用减少进程进入内核的攻击面AppArmor通过 profile 限制进程访问文件、网络、能力和其他资源eBPF通过内核 hook 提供高性能观测并可扩展到网络、运行时检测和安全策略三者不是互相替代而是位于不同层次的防御能力真正可靠的容器安全依赖最小权限、分层控制、持续观测和可回滚的工程流程。最终建议把安全策略当成代码来维护。每次镜像、内核、运行时或业务依赖升级都重新验证 Seccomp、AppArmor 和 eBPF 规则而不是把一次成功启动当成安全证明。参考资料Linux Kernel Documentation - eBPFhttps://docs.kernel.org/bpf/index.htmleBPF 官方文档https://ebpf.io/what-is-ebpf/Linux Kernel Documentation - Seccomphttps://docs.kernel.org/userspace-api/seccomp_filter.htmlDocker Seccomp 安全配置https://docs.docker.com/engine/security/seccomp/Ubuntu AppArmor 文档https://documentation.ubuntu.com/server/how-to/security/apparmor/Kubernetes Security Contexthttps://kubernetes.io/docs/tasks/configure-pod-container/security-context/Linux capabilities 手册https://man7.org/linux/man-pages/man7/capabilities.7.htmlCSDN 标签Linux云原生容器安全eBPFAppArmorSeccompDockerKubernetes内核安全DevSecOps