AppArmor profile 编写关键在于路径匹配准、模式切换对、加载时机对；文件名须严格对应可执行文件绝对路径（如/usr/local/bin/myapp对应/etc/apparmor.d/usr.local.bin.myapp），加载前需确认内核模块启用且工具链已安装，推荐先complain后enforce，并重启服务生效。
AppArmor profile 编写和加载不难，但细节决定成败。关键不是写得多全，而是路径匹配准、模式切换对、加载时机对。
profile 文件名必须严格对应程序路径
AppArmor 不看进程名，只按 可执行文件的绝对路径 匹配 profile。比如你要约束 /usr/local/bin/myapp，profile 文件名就得是：
-
/etc/apparmor.d/usr.local.bin.myapp（点号替代斜杠） - 不能叫
myapp或usr-bin-myapp - 支持通配符如
/usr/local/bin/*，但需谨慎，避免过度授权
文件名错，apparmor_parser -r 会静默忽略，aa-status 里也看不到该进程受保护。
加载前先确认环境就绪
两件事缺一不可：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
-
内核模块已启用：运行
cat /sys/module/apparmor/parameters/enabled，输出Y才算激活；如果报错或为空，说明内核没加载 AppArmor，装工具也没用 -
工具链已安装：
which apparmor_parser必须有输出；Ubuntu/Debian 用户常漏装apparmor-utils，直接运行sudo apt install apparmor-utils
最小化系统（如某些云实例或容器）可能默认禁用 AppArmor，得检查启动参数是否含 security=apparmor，并确认 /sys/kernel/security/apparmor/ 目录存在。
从 complain 模式起步，再切 enforce
新 profile 别一上来就强制拦截，容易把服务搞挂。推荐流程：
- 先用
sudo aa-complain /etc/apparmor.d/usr.local.bin.myapp启用投诉模式 - 正常运行服务一段时间，查
dmesg | grep apparmor或journalctl -k | grep DENIED，看哪些访问被拦了但实际需要 - 根据日志补全 profile 规则，再执行
sudo aa-enforce /etc/apparmor.d/usr.local.bin.myapp
切换模式无需重载 profile，aa-complain 和 aa-enforce 会直接通知内核更新策略状态。
加载后必须重启服务才能生效
profile 加载进内核 ≠ 进程自动受保护。只有新启动的进程才会匹配策略：
- 用
systemctl restart myapp.service最可靠，尤其当 unit 文件里配置了AppArmorProfile= - 手动
kill -9 && ./myapp可能绕过 systemd 的 profile 绑定，导致仍显示unconfined - 验证是否生效：运行
aa-status | grep myapp，看到进程名和对应 profile 行才算成功
