Linux AppArmor 开发模式调试 操作教程

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 权限