Linux如何配置AppArmor安全框架_Linux AppArmor安全框架配置指南

Ubuntu/Debian 上 apt 安装的 Nginx 默认 AppArmor 策略过严，需手动添加精确路径规则

在 Ubuntu 或 Debian 系统上，通过 apt 安装的 Nginx 会自带一个 AppArmor 安全策略。这个默认策略的限制往往过于严格，如果不手动补充网站所需的精确路径规则，服务大概率会启动失败，或者出现恼人的 502、403 错误。

确认 AppArmor 是否真在拦你

遇到 Nginx 启动失败，或者日志里频繁出现 Permission denied、operation not permitted 这类提示时，先别急着排查其他配置，AppArmor 很可能就是那个“幕后黑手”。

怎么确认？靠猜可不行，得看证据。按顺序执行下面几条命令，真相一目了然：

sudo aa-status —— 首先确认 AppArmor 模块已启用，并且 /usr/sbin/nginx 出现在 “profiles are loaded” 的列表里。

sudo journalctl -u nginx --since “1 hour ago” | grep -i denied —— 这条命令是关键，它能直接抓取系统日志中近一小时内被 AppArmor 拒绝的记录。

sudo aa-status | grep nginx —— 最后检查一下 Nginx 的 profile 当前是运行在 enforce（强制）模式还是 complain（抱怨）模式。生产环境务必使用 enforce 模式以保证安全。

往 /etc/apparmor.d/usr.sbin.nginx 里加什么规则

定位到问题后，下一步就是编辑策略文件：/etc/apparmor.d/usr.sbin.nginx。核心原则是：规则不是越宽泛越好，而是越精确越安全、越稳定。

找到文件中 /usr/sbin/nginx PUx, 这一行，在其下方追加你实际部署需要用到的路径。以下是几个最常见的场景和对应的规则写法：

网站根目录（例如 /var/www/myapp）：/var/www/myapp/** r,（如果只需要读取权限）或 /var/www/myapp/** rwk,（如果需要读写、创建和文件锁权限）。

PHP-FPM 套接字（例如 /run/php/php8.1-fpm.sock）：/run/php/php*.sock rw,（使用通配符更稳妥，可以避免 PHP 版本升级后规则失效）。

SSL 私钥文件（例如 /etc/ssl/private/mydomain.key）：/etc/ssl/private/** r,（注意：AppArmor 只负责允许进程读取该路径，文件本身的权限仍需设置为 600）。

自定义日志路径（例如 /var/log/nginx/myapp.access.log）：/var/log/nginx/myapp.* log,（这里的 log 是 AppArmor 的特殊权限关键字，能更好地兼容 logrotate 等日志轮转工具）。

⚠️ 这里有个重要的提醒：务必避免使用像 /var/** 这样过于宽泛的规则。这不仅完全违背了安全策略的初衷，还可能被后续的安全审计工具标记为高危漏洞。

改完规则后怎么让 Nginx 真的用上

修改配置文件只是第一步，AppArmor 规则不会自动生效。必须执行 reload + restart 两步操作，而且顺序不能错，缺一不可。

sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx —— 首先重载这个单独的 profile。这比重启整个 AppArmor 服务更轻量，也更安全。

sudo systemctl restart nginx —— 紧接着，必须重启 Nginx 服务。新的进程才会按照刚加载的新策略来运行。

sudo aa-status --verbose | grep nginx —— 最后验证一下，确保 profile 已成功加载，并且输出中没有 parse error 之类的语法错误。

如果重启后问题依旧，可以临时将 Nginx 切换到 complain 模式来收集完整的拒绝事件：先执行 sudo aa-complain /usr/sbin/nginx，然后复现问题请求，最后运行 sudo aa-logprof 来生成建议规则。不过要小心，这个方法生成的规则往往偏宽泛。

为什么 aa-logprof 生成的规则总不准

这就引出一个常见误区：为什么不能完全依赖 aa-logprof 来自动生成规则？原因在于它的工作原理有局限性。

aa-logprof 只能看到那些“已经被策略拦住的事件”，却无法知晓“哪些行为虽然没被拦，但也不应该被放行”。因此，它的建议天生倾向于添加更宽泛的路径，以求“一劳永逸”。

举个例子：你的 Nginx 实际上只访问了 /run/php/php8.1-fpm.sock 这一个套接字文件，但 aa-logprof 可能会建议你开放 /run/php/** rw, 这样整个目录的读写权限。它无法智能地区分生产环境套接字、临时文件或调试用的 socket。

所以，真正可靠、安全的规则，必须基于你明确知晓的部署路径来手动编写，而不是直接复制粘贴 aa-logprof 的输出。一个可行的流程是：在调试阶段，先用 complain 模式配合 aa-logprof 快速定位问题；但在上线部署前，一定要人工逐条核对并收紧这些自动生成的规则。

最后，还有两个最容易被忽略的细节：第一，AppArmor 策略只对新启动的进程生效。这意味着，改了配置如果不重载策略，或者重载了策略却不重启 Nginx 服务，所有修改都等于白费功夫。第二，路径规则中末尾的 **（匹配任意多层目录）和 *（匹配单层目录）语义完全不同，写错了不会导致语法报错，但会导致规则静默失效，这个问题尤其隐蔽。