AppArmor profile 怎么切换 complain 模式收集拒绝日志

AppArmor 排查某个服务“偶尔打不开文件”时，比较稳妥的做法不是把整台机器切成 complain，而是只把目标 profile 临时切换到 complain，复现一次业务，再从审计日志里确认真实访问路径。收集完成后立即切回 enforce。

官方资料：https://ubuntu.com/server/docs/security-apparmor/

需要先记住一个容易混淆的点：complain 模式通常不会拦截原本不匹配的访问，但仍会记录策略事件；因此日志里可能看到 ALLOWED，不一定都是 DENIED。显式 deny 规则仍有自己的语义，不能把 complain 当成“完全关闭 AppArmor”。

先确认 profile，再切换模式

先确定真正加载的 profile 名称和对应文件。AppArmor 的 profile 常放在 /etc/apparmor.d/，但文件名、profile 名和进程可见名称不一定完全相同。不要凭服务名直接对全局策略动手。

# 查看当前加载的 profile 与模式，先确认目标是否存在
sudo aa-status

# 只针对示例 profile 文件切换，替换成你的真实文件名
sudo aa-complain /etc/apparmor.d/usr.sbin.myservice

aa-status 用来观察当前加载、enforce 和 complain 的数量；它是状态检查，不是把所有 profile 一起切换。若目标 profile 不在加载列表里，先处理 profile 是否加载的问题，不要连续重复执行切换命令。

只让目标 profile 进入 complain

aa-complain 接受一个或多个目标程序/profile，并默认从 /etc/apparmor.d 查找策略。这里的重点是“单个”：排障期间只降低被观察服务的策略强度，其他服务继续保持 enforce。

如果使用了 --no-reload，不要误以为内核已经采用新模式；修改只是暂存到 profile 文件，后续还要按你的发布方式重新加载。日常排障更适合第一条命令，改完立即生效后再开始复现。

复现业务并读取日志字段

切换完成后，只复现出现问题的那条业务路径，例如启动服务、读取配置或执行一次定时任务。不要在 complain 状态下把所有功能都无边界地跑一遍，否则日志会混入大量不属于生产工作负载的访问。

一条事件至少要看这些字段：profile 表示哪个策略命中，operation 表示操作类型，name 表示目标资源，requested_mask 表示请求的权限，pid 和 comm 帮助定位进程。把这些字段和业务复现时间对齐，才能判断某条访问是否真的属于应用必需行为。

apparmor="ALLOWED" operation="open" profile="/usr/sbin/myservice" name="/etc/myservice.conf" requested_mask="r" pid=412 comm="myservice"

上面的日志行只用于说明字段关系，不代表你的机器一定会输出完全相同的顺序或内容。不同发行版可能把事件写入 syslog、auditd 日志或 systemd journal，关键是围绕目标 profile 和复现时间筛选。

收集完成后恢复 enforce

日志收集完就恢复拦截能力。即使还没有决定是否补规则，也不要让生产 profile 长时间停留在 complain；先回到安全默认状态，再离线整理最小规则。

恢复后再次触发同一操作，若策略确实不允许，应用可能重新出现被拦截的错误，同时审计日志会记录相应事件。这个“恢复后再观察”的动作是为了确认模式已经回到生产边界，不是让 complain 永久替代规则设计。

几个容易把排障带偏的边界

• 不要全局切换 complain。全局模式会同时降低所有 profile 的保护，单服务排障没有必要扩大影响面。
• 不要把 ALLOWED 当成无条件放行建议。日志只说明应用尝试过某个访问，是否应该写入策略，还要结合业务职责、路径敏感性和最小权限判断。
• 注意子 profile 和 hat。主 profile 切换后，子 profile 可能有独立模式，看到日志时要核对事件里的完整 profile 名。
• 显式 deny 不能忽略。官方手册说明，deny 规则在 complain 模式下仍可能被执行；遇到持续拒绝，先回看策略中的 deny 规则。

可以把流程压缩成一句话：确认单个 profile → aa-complain → 按真实业务复现 → 读取 profile/operation/name 等字段 → aa-enforce 恢复。这样既能收集排障线索，也不会把生产主机变成全局宽松模式。

相关问题

complain 模式是不是完全不拦截？

不是。通常未匹配访问会被记录而不被拦截，但显式 deny 规则仍有自己的执行效果，不能把它当作关闭 AppArmor。

为什么日志里出现 ALLOWED 而不是 DENIED？

这是 complain 模式的常见表现：原本会触发策略违规的访问被记录为允许事件。应结合 profile、operation、name 和复现时间判断，而不是只搜索 DENIED。

恢复 enforce 后要不要立刻修改 profile？

不必把每一条日志都直接写成允许规则。先筛掉测试路径和非生产行为，再按最小权限原则审查，确认规则后单独 reload 并复查。