AppArmor 与两种模式
AppArmor 是 Ubuntu、Debian、SUSE 上基于路径的强制访问控制（MAC）：它为每个程序挂一份 profile，声明该进程能访问哪些文件、目录与能力，超出范围的访问被拒绝。profile 有两种运行状态，enforce 会真正阻断违规访问，complain 只记录不阻断。加固重点就是确认 sshd、nginx、数据库等关键服务的 profile 处于 enforce，而不是长期停在 complain 观察态。
基本信息
| 适用平台 | Linux（Ubuntu/Debian/SUSE 系，RHEL 系等价物为 SELinux） |
|---|---|
| 权限要求 | root（或 sudo） |
| 常用工具 | aa-status、aa-enforce、aa-complain、apparmor_parser |
| profile 目录 | /etc/apparmor.d/ |
| 基线 | 关键服务的 profile 处于 enforce mode |
典型使用场景
- 基线核查：统计已加载 profile 数与 enforce、complain 的分布
- 排障收尾：把临时切到 complain 的 profile 切回 enforce
- 自定义策略上线：为新部署的服务编写并加载 profile
- 服务加固：限制 Web 服务只能读取站点目录，降低被入侵后的影响面
- 合规检查：强制访问控制机制是否真正启用并生效
核查与单 profile 操作
核查与单 profile 操作
sudo aa-status | head -20 # 各状态计数与 profile 列表
sudo aa-status --complaining | head # 只看仍处于 complain 的项
sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx # 切换为强制模式
sudo aa-complain /etc/apparmor.d/usr.sbin.nginx # 排障时切回观察模式
sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx # 重载单个 profile
dmesg | grep -i apparmor | tail -5 # 查看 denied 记录定位越权访问输出逐列读法
| 视图/字段 | 含义 | 正常与异常 |
|---|---|---|
| profiles are loaded | 已加载的 profile 总数 | 为零说明策略未加载或未启用 |
| profiles are in enforce mode | 强制模式数量 | 关键服务不在其中=策略未生效 |
| profiles are in complain mode | 观察模式数量 | 长期非零说明整改未闭环 |
| processes are unconfined | 未受约束的进程数 | 关键服务出现在此列需处置 |
| dmesg 的 denied | 被拒绝的访问记录 | 排障高价值线索，也可能是策略过严 |
complain 模式只记录不阻断，属于排障过渡态：生产机要定期核查是否遗留长期不放的 profile，那等于策略没有生效。
落地要点
- aa-status 需要 root 权限，自动化巡检脚本要以 sudo 运行，否则输出不全
- 自定义 profile 先在测试机以 complain 观察足够长时间，再切 enforce
- 每次 profile 变更记入配置管理，便于回溯是谁在什么时候放开了哪条规则
- 被拒绝的访问既可能是攻击行为，也可能是策略过严，结合业务日志判断
- 确认内核已启用 AppArmor：部分发行版需要内核参数配合，否则策略只是摆设
同类的强制访问控制还有 SELinux：RHEL 系默认使用它，两者不要在同一台机器上重复配置，按发行版选一套并保持一致。