AppArmor profile 怎样区分 enforce 与 complain

我在排查 Linux 服务被 AppArmor 影响时，最先确认的不是“有没有日志”，而是 profile 当前到底处于 enforce 还是 complain。两者都可能留下审计记录，但前者会阻止不被规则允许的操作，后者通常会放行这类操作并把违规记下来。

官方地址：https://documentation.ubuntu.com/security/security-features/privilege-restriction/apparmor/

判断口诀：看 profile 状态，再看违规结果；DENIED 说明操作被 AppArmor 拦截，ALLOWED 说明它在 complain 语义下被记录但没有被该 profile 阻止。complain 不是全局放行，Linux 文件权限和其他安全限制仍然有效。

先看清 enforce 与 complain 的分工

AppArmor profile 描述某个程序可以访问哪些文件、能力或其他资源。profile 被加载后，内核根据当前模式处理不匹配规则的操作：

这里的“通常”很重要：complain 只改变 AppArmor 对 profile 违规的处理，不会替代 Linux DAC 权限，也不会绕过其他内核安全模块、挂载选项或服务自身的错误。

用状态命令确认 profile 当前处于哪一档

不要仅凭配置文件里的印象判断。先查看已经加载到内核的 profile 状态，再决定是否切换。Ubuntu 文档同时给出了 apparmor_status 和常用的 aa-status 入口，具体可用命令取决于系统安装的工具包。

# 查看已加载 profile 的数量以及各自的模式
sudo aa-status

# 某些发行版提供同义的状态命令
sudo apparmor_status

输出中要找的是目标 profile 的名字和状态，而不是只看“AppArmor 已启用”。一个服务的 profile 可能已加载，但当前仍是 complain；也可能 profile 没有加载，程序因此处于 unconfined 状态，这两种情况都不能当成 enforce。

从日志区分“被拦截”还是“被记录”

同一条未授权访问在两种模式下最有辨识度的差别，是审计记录里的操作结果。Ubuntu 文档提到日志通常进入系统日志或 auditd 日志；可以先按服务名、profile 名和 apparmor 字段缩小范围。

# 在系统日志中筛选 AppArmor 事件，避免把普通应用错误混在一起
sudo journalctl -k -g 'apparmor='

# 如果系统启用了 auditd，再查看独立审计日志
sudo grep 'apparmor=' /var/log/audit/audit.log

看到 apparmor="DENIED" 时，当前操作确实被 AppArmor 拒绝了；看到 apparmor="ALLOWED" 时，不能简单理解成“这条规则已经允许”，它也可能表示 complain 模式下本来会被 profile 拒绝、但这次被记录后放行的动作。还要结合 profile、operation、name 和进程信息判断是不是目标服务。

排障时怎样切换到 complain

如果服务刚接入 profile，还不清楚它会访问哪些目录，短时间切到 complain 可以先观察行为，避免一上来就因为缺规则而中断服务。切换对象应写成 profile 对应的可执行文件路径，并在完成观察后回到 enforce。

# 先把目标 profile 切到 complain，记录违规但暂不由该 profile 阻断
sudo aa-complain /path/to/service

# 观察服务完成一次真实业务后，再从内核日志中整理缺失规则
sudo journalctl -k -g 'apparmor=' --since '10 minutes ago'

这一步的产物不是“日志里出现了 ALLOWED 就直接复制规则”，而是一个待审核的访问清单：哪些路径确实属于业务需要，哪些是异常输入触发的偶发访问，哪些应当继续拒绝。把所有 ALLOWED 都加进 profile 会扩大权限边界。

规则稳定后怎样恢复 enforce

当规则已经补齐并完成业务回归，使用 aa-enforce 把 profile 恢复到阻断模式。切换后再看一次状态和内核日志，重点关注业务真正需要的访问是否仍出现新的 DENIED。

# 恢复 profile 的强制执行模式
sudo aa-enforce /path/to/service

# 确认状态命令已经显示为 enforce，再继续观察服务日志
sudo aa-status
sudo journalctl -k -g 'apparmor=' --since '5 minutes ago'

如果切回 enforce 后服务报出“文件不存在”“连接失败”或“权限不足”，不要只看应用层错误。先按 profile、operation、资源路径和时间戳去找对应的 DENIED 事件，再判断是漏写规则、路径变量不匹配，还是本来就应该拒绝的行为。

几个容易误判的边界

1. 看到 ALLOWED 不等于 profile 规则已经放开。在 complain 模式下，ALLOWED 可能只是“违规被记录但没有被该 profile 阻断”。
2. 看到 DENIED 不一定只需要改 AppArmor。先确认 profile 名和操作类型，再区分 AppArmor 拒绝、文件所有者权限拒绝或其他内核限制。
3. profile 没加载不等于 enforce。未加载时程序可能处于 unconfined，应该先解决加载和匹配问题。
4. complain 不应长期代替保护。它适合收集行为和定位缺规则，生产环境的最终状态通常应回到经过审核的 enforce。

我会怎样做最后判断

我通常按“状态、结果、原因”三层判断：第一层用 aa-status 确认目标 profile 已加载且当前模式明确；第二层看日志中的 DENIED 或 ALLOWED；第三层结合 profile 名、操作类型和资源路径，确认这是不是该服务真正需要的行为。只要这三层能够对上，就不会把 complain 误认为安全策略已经关闭，也不会把应用层权限错误全部归到 AppArmor。

相关问题

enforce 和 complain 都会写日志吗？

都会记录 AppArmor 相关事件，但违规操作的结果不同：enforce 重点表现为拒绝，complain 重点表现为记录后放行。仍需结合具体 profile 和系统日志配置判断记录位置。

切到 complain 后服务仍然报权限错误，正常吗？

正常。complain 只改变 AppArmor profile 违规的处理，不会绕过传统文件权限、挂载限制、其他 LSM 或服务本身的权限检查。

什么时候应该切回 enforce？

当服务的必要访问已经被审核、profile 规则完成更新并经过业务回归后，就应切回 enforce；不要把收集日志阶段的临时状态当成最终安全配置。