AppArmor通过内核LSM钩子实时比对策略实现路径锁定与运行时隔离，采用“按需授权”原则，支持complain模式观察行为后生成最小化profile，并需配合内核升级、/dev/shm限制及seccomp等形成多层防护。
直接用 AppArmor 为容器进程设限，核心是“按需授权、路径锁定、运行时隔离”。它不依赖用户身份或进程名，而是通过内核 LSM 钩子，在系统调用入口处实时比对策略，哪怕攻击者拿到 root 权限，只要没绕过 AppArmor 规则，就无法访问未授权路径或执行危险操作。
明确目标进程并启用 complain 模式观察行为
先不强制拦截，让 AppArmor 记录真实行为，避免策略过严导致服务异常。比如你要保护一个运行在容器里的 Python Web 应用：
- 确认容器内主进程路径，如 /usr/bin/python3 /app/main.py
- 创建初始 profile：sudo aa-genprof /usr/bin/python3（交互式生成）或手动写入 /etc/apparmor.d/usr.bin.python3
- 加载为 complain 模式：sudo apparmor_parser -r /etc/apparmor.d/usr.bin.python3，此时拒绝行为只记日志不阻断
- 运行容器并触发典型业务流程（如上传文件、读配置、连数据库），再用 sudo aa-logprof 分析 /var/log/kern.log 中的 audit 日志，自动补全所需路径和权限
编写最小化 profile：聚焦路径、网络与 IPC 控制
最终 profile 应只放行必要项。以 Python 进程为例，典型安全约束包括：
- 文件系统：只读访问 /app/**，仅允许写入 /tmp/ 和 /var/log/app/；禁止访问 /etc/shadow、/proc/**、/sys/**、/dev/shm（防 LPE 利用）
- 网络：限制绑定端口，如 network inet stream, 但禁止 bind to port 1-1023；若只需出站，可加 deny network inet raw,
- IPC 与共享内存：显式拒绝 /dev/shm/** mrw, 或更严格地 deny /dev/shm/**, 防止通过 shm_open + mmap(PROT_EXEC) 注入恶意代码
- 能力与执行：禁用 capability sys_admin, capability dac_override, 并设置 deny /bin/sh px, deny /usr/bin/bash px, 阻断常见提权链
绑定容器运行时并启用强制模式
profile 写好后，不能只靠名字匹配——必须确保容器内进程实际加载该策略：
- 给 profile 赋予唯一名称，如 abac-container-web，并在文件顶部声明：profile abac-container-web /usr/bin/python3 {
- 加载进内核：sudo apparmor_parser -r /etc/apparmor.d/usr.bin.python3
- Docker 启动时指定策略：docker run --security-opt apparmor=abac-container-web ...
- 验证是否生效：docker exec -it
cat /proc/1/attr/current 应返回 abac-container-web (enforce)
配合宿主机级防护堵住绕过路径
AppArmor 不是银弹。CrackArmor 类漏洞表明，若内核 AppArmor 模块本身存在缺陷（如 v4.11+ 的九个混淆代理漏洞），攻击者可能通过伪文件或 Sudo 交互绕过策略。因此必须同步加固底层：
- 立即升级内核至已修复版本（Ubuntu/Debian/SUSE 已发布补丁，检查 apt list --upgradable | grep linux-image）
- 限制 /dev/shm：在 /etc/fstab 中设 size=64M,noexec,nosuid,nodev，再 sudo mount -o remount /dev/shm
- 禁用容器特权启动：--privileged=false（默认），且不挂载 /proc、/sys 等敏感路径
- 结合 seccomp 过滤高危系统调用（如 clone、execveat、userfaultfd），形成多层过滤
