apparmor 是为填补传统 unix 权限无法限制程序行为的空白而设计的进程级最小权限沙箱机制，它基于路径实施强制访问控制（mac），需完成写 profile、加载到内核、验证生效三步才真正起作用。
Linux 权限体系中，传统 Unix 用户/组权限（rwx）仅控制“谁可以访问什么”，但无法限制“一个程序能做什么”。AppArmor 就是为填补这一空白而设计的运行时权限限制机制——它不替代用户权限，而是叠加一层基于路径的强制访问控制（MAC），让代码在启动后只能碰明确允许的资源。
AppArmor 的核心定位：进程级最小权限沙箱
它不是全局开关，而是为每个可执行文件单独配策略。比如 /usr/bin/python3 和 /opt/myapp/server 可以拥有完全不同的规则集。策略生效前提是：内核模块已启用、profile 已加载、目标进程由该 profile 覆盖。它不管你是 root 还是普通用户，只看“这个二进制正在跑，它被允许干什么”。
三步落地：写、载、验
配置真正生效必须走完这三步，缺一不可：
-
写对 profile：放在
/etc/apparmor.d/下，文件名按路径转点（如/usr/local/bin/worker→usr.local.bin.worker）；开头加#include <tunables></tunables>；规则末尾带逗号；路径用绝对路径；只放真实需要的条目（例如/var/lib/myapp/** rwk,，而非/var/** rwk） -
载入内核：用
sudo apparmor_parser -r /etc/apparmor.d/usr.local.bin.worker（-r表示替换已有规则）；若报语法错，用sudo apparmor_parser -t /etc/apparmor.d/usr.local.bin.worker先试运行检查 -
验证生效：运行
sudo aa-status确认该 profile 在 “enforce mode” 列表中；再查sudo dmesg | grep -i "apparmor.*denied"，有日志说明它真在拦；没日志且服务正常，大概率已按预期工作
关键权限项怎么设才安全
一份实用的 profile 不是堆功能，而是裁剪风险面：
-
文件权限：显式允许必要路径（
/run/myapp/sock w,），同时用deny /etc/shadow r,、deny /home/** rwx,封死常见提权入口 -
网络控制：只开实际用的协议和类型，例如
network inet stream,（本地 TCP），禁用network netlink raw,防路由劫持 -
能力（capability）：默认全禁，只加必需项，如
capability setuid,、capability dac_override,（仅当程序确实需切换用户或绕过权限检查时才放开）
容器场景下不能只靠默认策略
Docker 默认用 docker-default profile，它宽松且通用。生产环境应为关键容器指定自定义 profile：
- profile 文件名按容器内进程路径命名（如容器里跑
/app/main，文件名为app.main） - Docker 启动时加
--security-opt apparmor=app.main - Kubernetes 中通过 annotation：
container.apparmor.security.beta.kubernetes.io/<container-name>: localhost/app.main</container-name> - 务必在 profile 中 deny 敏感路径：
deny /proc/sys/** w,、deny /sys/firmware/** rwklx,、deny /dev/.lxc/* r,（防容器逃逸）
AppArmor 不复杂，但容易忽略验证环节。很多“权限没生效”的问题，其实只是 profile 没加载、或进程没被正确匹配到策略。盯住 aa-status 和 dmesg，比反复改配置更有效。
