服务器AppArmor配置：从启用、调整到排错的实操步骤

AppArmor 是 Linux 内核提供的一种强制访问控制机制，可以限制某个程序能读写哪些文件、能使用哪些网络能力。
如果你在 Ubuntu 或 Debian 服务器上运行 Nginx、MySQL、Docker，系统通常已经默认启用了 AppArmor。服务器 AppArmor 配置的核心思路是：先确认当前状态，再根据程序实际需要调整策略，最后验证是否生效，而不是直接关闭它。

本文适用于 Ubuntu 22.04/24.04 或 Debian 12 等使用 AppArmor 的服务器，操作需要 root 或 sudo 权限。
执行前建议先对关键配置做备份，避免误改导致服务无法启动。

先确认 AppArmor 是否在运行

登录服务器后，先检查内核模块和用户态工具是否就绪：

sudo aa-status
sudo systemctl status apparmor

如果 aa-status 输出类似 apparmor module is loaded，并列出 enforce、complain 模式下的进程数量，说明 AppArmor 正常工作。
若提示命令不存在，可安装：

sudo apt update
sudo apt install apparmor apparmor-utils

安装后再次执行 sudo aa-status。
预期结果是看到已加载的策略列表，例如 nginx、docker 等。

理解 enforce 与 complain 两种模式

AppArmor 对每个程序有两种主要工作模式：

• enforce：按策略执行，违规操作会被拒绝，程序可能报错或功能异常。
• complain：只记录违规行为，不拦截，适合调试规则。

查看某个程序的当前模式：

sudo aa-status | grep nginx

切换模式时，先切到 complain 观察日志，确认没有异常再切回 enforce：

sudo aa-complain /etc/apparmor.d/usr.sbin.nginx
sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx

修改模式后无需重启 Nginx，AppArmor 会立即生效。

为 Nginx 添加自定义访问规则

当 Nginx 需要访问默认策略未允许的目录时，会出现权限拒绝。
例如你把网站根目录改到 /data/www，Nginx 可能无法读取。

先查看 Nginx 的策略文件路径：

ls /etc/apparmor.d/ | grep nginx

常见文件为 /etc/apparmor.d/usr.sbin.nginx。
编辑前备份：

sudo cp /etc/apparmor.d/usr.sbin.nginx /etc/apparmor.d/usr.sbin.nginx.bak
sudo vi /etc/apparmor.d/usr.sbin.nginx

在文件末尾的 } 之前添加允许规则，例如允许读写 /data/www 和日志目录：

/data/www/ r,
/data/www/** rwk,
/var/log/nginx/** rw,

保存后重新加载策略：

sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx

然后重启 Nginx 并访问站点，确认页面正常打开。

处理常见的权限拒绝报错

AppArmor 拒绝操作时，内核日志会记录 apparmor="DENIED"。
用下面命令实时查看：

sudo dmesg | grep -i apparmor
sudo journalctl -k | grep apparmor

如果看到类似 operation="open" denied_mask="r" name="/data/www/index.html"，
说明需要为对应路径添加读权限。

另一种情况是服务启动失败但日志不明确。
可以临时把该程序切到 complain 模式，重现操作后再看日志：

sudo aa-complain /etc/apparmor.d/usr.sbin.nginx
sudo systemctl restart nginx

根据日志补充规则后，再切回 enforce 模式。不要长期停留在 complain 模式，否则安全限制等于没有生效。

避坑与验证

调整 AppArmor 时容易踩的坑：

• 直接执行 sudo systemctl stop apparmor 或卸载 AppArmor，虽然省事，但会失去一层安全防护。
• 修改策略后忘记执行 apparmor_parser -r，规则不会重新加载。
• 规则路径写错，例如漏掉末尾的 / 或 **，导致通配不生效。
• 多个策略文件冲突时，以实际加载的 profile 为准，可用 sudo aa-status 确认。

验证配置是否生效，可以故意访问一个未授权的路径，观察是否被拒绝，同时在 dmesg 中查看是否有对应 DENIED 记录。
如果服务功能正常且日志无异常拒绝，说明配置基本可用。

总结：
服务器 AppArmor 配置应先确认状态，
再用 complain 模式收集日志，
按需补充路径规则，
最后切回 enforce 并验证。 如果你的服务器运行的是宝塔面板或其他自编译环境，
策略文件位置可能不同，
建议先用 aa-status 定位实际 profile 名称再操作。