AppArmor 日志出现 DENIED 时怎么用 aa-logprof 定位

AppArmor 日志出现 DENIED 时，最稳妥的顺序不是马上给程序放开权限，而是先确认拒绝事件中的 profile、operation 和目标路径，再让 aa-logprof 根据日志提出候选规则。这样可以把“程序报权限错误”缩小为某个 profile 对某个对象的具体访问。

官方资料：https://documentation.ubuntu.com/server/how-to/security/apparmor/

核心判断：DENIED 只说明当前 profile 没有允许这次访问，不等于应该直接改成宽泛的 /** 或关闭 AppArmor。先看事件，再按最小范围选择规则，最后重新加载并观察同类记录是否消失。

先读懂 DENIED 记录里的三个字段

AppArmor 事件通常会写入 audit 日志，也可能出现在系统日志中。先把日志范围缩小到 AppArmor，再看同一条记录中的三类信息：哪个 profile 做了限制、程序尝试了什么操作、目标对象是什么。普通的 Permission denied 只能说明应用层失败，不能单独证明是 AppArmor 造成的。

# 只筛选 AppArmor 拒绝事件，避免把普通权限错误混在一起
sudo journalctl -k --no-pager | grep -E 'apparmor="DENIED"|apparmor.*DENIED'

# 发行版启用 auditd 时，也可以从审计日志中读取同类记录
sudo grep -E 'apparmor="DENIED"|apparmor.*DENIED' /var/log/audit/audit.log

重点不是背日志格式，而是确认字段的对应关系：profile 是生效的策略身份，operation 描述读取、写入、执行等访问动作，name 或相邻路径字段指向目标文件、目录、套接字或其他对象。记录里的 requested_mask、denied_mask 可以帮助判断请求权限与被拒权限是否一致。

先确认 profile 模式，再让日志变得可用

Ubuntu 文档把 AppArmor profile 的常见模式分为 complain 和 enforce。complain 会记录违规但通常允许访问，适合在受控范围内收集程序行为；enforce 会在记录的同时执行限制。已有生产 profile 时，先查看状态，不要为了排障把所有 profile 一起切到学习模式。

# 查看当前加载的 profile 及其模式，先确认目标 profile 的精确名字
sudo aa-status

# 仅对目标 profile 开启 complain，便于收集缺失访问
# 把示例名称替换成 aa-status 输出中的实际 profile
sudo aa-complain /etc/apparmor.d/usr.sbin.example

# 收集完成后恢复 enforce，避免学习模式长期扩大权限面
sudo aa-enforce /etc/apparmor.d/usr.sbin.example

如果 profile 已经处于 complain，日志中的事件更适合用来建立最小权限集合；如果处于 enforce，先判断拒绝是否确实对应业务必需动作。不要用“让错误消失”作为唯一目标，因为一个过宽的允许规则可能把不相关目录、子进程或凭据文件一起纳入访问范围。

用 aa-logprof 筛选规则建议

aa-logprof 是交互式工具，会扫描日志中的 AppArmor 事件，并针对当前 profile 尚未覆盖的访问给出建议。它不是自动批准器：每条建议都要结合目标路径、操作类型和程序职责判断。直接运行即可使用默认日志位置；日志路径特殊时再显式指定。

# 让 aa-logprof 读取默认日志位置并交互式呈现新增事件
sudo aa-logprof

# 日志不在默认位置时，显式指定包含 AppArmor 事件的文件
# -f 只改变输入来源，不会替你判断规则是否安全
sudo aa-logprof -f /var/log/audit/audit.log

交互界面通常会展示 profile、路径、旧模式、新模式和候选项。对文件或目录，优先选择能覆盖当前业务且范围最窄的规则；对可疑或不必要的访问可以选择 deny 或 ignore。尤其要留意工具提供的 glob 建议：/srv/app/cache/* 与 /srv/app/** 的覆盖面不同，后者会把更深层级内容一并纳入。

涉及执行权限时更要谨慎。父 profile 调用子程序可能出现独立 profile、继承父 profile 或拒绝访问等选择，不能仅因一次日志事件就把目标程序设置为不受约束执行。先确认子程序的信任边界和需要的文件权限，再决定是否拆出独立 profile。

规则写入后，重新加载并复查最小权限

选择建议后，aa-logprof 会把修改写回 profile；Ubuntu 文档也提示，profile 文件变更后需要重新加载才能让内核使用新内容。若你手动编辑了规则，可以显式重载对应文件。

# 重新加载单个 profile，让内核采用文件中的最新规则
# 路径必须指向实际的 profile 文件
sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.example

# 再次查看状态，确认目标 profile 仍处于预期模式
sudo aa-status | grep -F 'usr.sbin.example'

复查时看三件事：第一，规则是否写进了被拒事件对应的 profile，而不是同目录下相似名称的文件；第二，是否因为方便而选用了过宽的通配符；第三，业务动作恢复后是否仍有新的 DENIED。如果仍有拒绝，不要立刻把新路径全部允许，先比较新的 operation、目标路径和调用场景，确认它是同一缺口还是另一条策略边界。

常见问题

aa-logprof 会自动把所有拒绝都允许吗？

不会。它提供候选修改并等待选择，用户可以允许、拒绝、忽略或退出；候选规则仍需要按 profile 职责和路径范围判断。

只看到 Permission denied，为什么没有 DENIED？

可能是 Unix 用户权限、ACL、文件系统挂载选项或日志位置不同。先确认内核日志或 audit 日志中是否真的有 AppArmor 事件，再决定是否使用 aa-logprof。

排障结束后一定要恢复 enforce 吗？

如果只是为了学习业务访问而临时使用 complain，收集完成后应恢复 enforce，并重新检查新增规则，避免把临时观察状态变成长期权限放宽。

把 AppArmor 的 DENIED 当作一条可拆解的策略证据：先识别 profile、操作和目标，再用 aa-logprof 缩小候选，最后重新加载并观察新的日志。这样既能解决具体访问问题，也能保留 profile 的权限边界。