apparmor调试核心是“观察—生成—精修—验证”四步闭环：先用complain模式记录越界行为，再通过aa-logprof生成宽泛规则，人工收紧后切enforce模式验证。
AppArmor 开发模式调试，核心是用 Complain 模式收全行为日志，再结合 aa-logprof 生成初步规则，最后人工收紧、切回 Enforce 模式。它不是一次写完就跑通，而是“观察—生成—精修—验证”四步闭环。
进入 Complain 模式收集真实访问行为
新服务或修改配置后，先不让 AppArmor 阻断操作，只记录所有越界访问：
- 运行 sudo aa-complain /usr/bin/your-program（路径必须和 profile 文件名一致，如
/usr/bin/python3对应/etc/apparmor.d/usr.bin.python3） - 若 profile 尚未加载，需先 sudo apparmor_parser -r /etc/apparmor.d/your-profile
- 重启目标程序，让它按 Complain 模式运行（策略只对新启动进程生效）
- 执行典型业务操作（如访问网页、上传文件、调用 API），触发尽可能多的文件/网络/能力请求
从日志生成基础 profile 规则
AppArmor 把拒绝行为记在内核日志里，aa-logprof 会自动解析并建议规则：
- 确保日志中有 APPARMOR_DENIED 条目：运行 sudo dmesg -t | grep -i apparmor 或查
/var/log/audit/audit.log - 执行 sudo aa-logprof，它会逐条提示检测到的越权行为，例如：
“Path: /tmp/myapp.sock — Allow read/write?” → 按 A 接受，W 写入 profile - 注意：它默认加
/tmp/** rw,这类宽泛规则不安全，务必手动改成精确路径，比如/tmp/myapp.sock rw,
精修 profile 并重载验证
自动生成的规则只是起点，必须人工审查和收紧：
- 打开 profile 文件（如
/etc/apparmor.d/usr.bin.myserver），检查每条路径是否必要；删掉未使用的network inet udp或capability sys_admin - 优先使用 abstraction（如
abstraction python）复用成熟权限集，避免重复写/usr/lib/python3.*/** r, - 路径中慎用
**，改用*或明确文件名；敏感路径如/etc/shadow绝对不能出现在 profile 里 - 保存后运行 sudo apparmor_parser -r /etc/apparmor.d/usr.bin.myserver 重载
- 再 sudo systemctl restart myserver 启动新进程，用 sudo aa-status | grep myserver 确认它已加载且处于 enforce 状态
快速确认是否真被 AppArmor 拦截
遇到 Permission denied、Operation not permitted 或服务启动失败时，别急着改权限，先排查 AppArmor：
- sudo aa-status → 查看模块是否启用、profile 是否加载、进程是否被约束
- sudo journalctl --since "5 minutes ago" | grep -i "apparmor.*denied" → 直接定位被拒动作
- 若 profile 显示为 complain 却仍有错误，说明问题不在 AppArmor，可能是 SELinux、文件系统挂载选项（noexec/nodev）或传统 Unix 权限
