传统的Linux权限模型（DAC，自主访问控制）依赖文件属主和rwx权限位来限制进程行为，一旦进程被入侵者控制，它就能以进程属主的身份访问该用户能触达的所有资源。强制访问控制（MAC）则不同，它由内核依据预定义的安全策略对进程行为进行强制约束，即使进程拥有root权限，超出策略允许范围的操作也会被拒绝。openSUSE从很早开始就深度集成了AppArmor，将其作为默认的安全框架之一。本文将系统讲解在openSUSE上配置和使用AppArmor的完整流程，包括策略文件编写、学习模式运用以及从complain过渡到enforce的实战方法。
理解AppArmor的工作原理与核心概念
AppArmor与SELinux同属主流的强制访问控制实现，但两者的设计哲学差异很大。SELinux基于标签（label），要求对整个文件系统打安全标签，配置复杂度高；AppArmor则基于路径（path-based），策略直接描述某个程序可以访问哪些文件路径、拥有哪些能力（capability）和网络权限，可读性和上手难度都友好得多。
AppArmor的核心单元是profile（配置文件），每个profile绑定到一个可执行程序的路径上。当该程序启动时，内核会将对应的profile加载到进程上，进程后续的每一次文件读写、网络连接、能力调用都会与profile中的规则比对。规则匹配则放行，不匹配则按模式处理：在enforce模式下直接拒绝并记录日志，在complain模式下仅记录违规但不拦截。
openSUSE中profile文件存放在/etc/apparmor.d/目录下，文件名通常以点号分隔表示程序路径，例如usr.sbin.nginx对应/usr/sbin/nginx。系统服务由apparmor.service管理，可以使用systemctl查看和启停。需要注意的是，AppArmor默认只限制被profile覆盖的程序，未被覆盖的进程不受任何额外约束，这与SELinux的默认全量覆盖策略截然不同。
常用管理工具与基本操作
openSUSE提供了apparmor-utils工具包，先确认它已安装：
# 安装工具包 sudo zypper install apparmor-utils # 查看AppArmor整体状态 sudo aa-status # 启动并设置开机自启 sudo systemctl enable --now apparmor.service # 重新加载所有已修改的策略 sudo systemctl reload apparmor.service
aa-status的输出会列出当前加载了多少profile、多少处于enforce模式、多少处于complain模式，以及哪些进程正被策略约束。这是排查问题时的第一入口。日常管理中还会频繁用到几个命令：单独加载某个策略用apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx，禁用某个策略用aa-disable，重新启用用aa-enforce，切换到学习模式用aa-complain。
日志是诊断AppArmor拦截行为的关键。被拒绝的事件会写入/var/log/audit/audit.log（若安装了auditd）或内核日志/var/log/messages，关键字为DENIED。通过journalctl -k | grep apparmor也能快速过滤出相关记录。看到DENIED并不一定是坏事，它恰恰是完善策略的素材来源。
编写Profile策略文件
一个典型的profile文件结构如下，我们以一个自定义服务为例：
#include <tunables/global>
/profile /usr/bin/myapp flags=(attach_disconnected) {
#include <abstractions/base>
#include <abstractions/nameservice>
# 可执行文件权限
/usr/bin/myapp mr,
# 配置文件只读
/etc/myapp/*.conf r,
# 日志目录可写
/var/log/myapp/ rw,
/var/log/myapp/*.log rw,
# 运行时数据
/var/lib/myapp/ rw,
# 网络权限
network inet stream,
network inet6 dgram,
# 允许的能力
capability setuid,
capability setgid,
# 明确拒绝敏感路径
deny /etc/shadow rwkl,
deny /root/** rwklx,
}
规则由路径、权限模式和一个可选的访问类型组成。常见的权限字母含义要记牢：r表示读，w表示写（含创建和删除），k表示锁定操作，l表示创建硬链接，m表示内存映射可执行，x表示执行（需配合ix、px、ux等执行修饰符，分别表示继承当前profile、切换到目标profile、无约束执行）。路径支持通配符：星号匹配不含斜杠的任意字符，双星号匹配任意层级目录，问号匹配单个字符。
#include <abstractions/base>引入了预定义的通用规则集，覆盖了共享库、设备文件等几乎所有程序都需要的基础访问，能大幅减少手写规则量。openSUSE在/etc/apparmor.d/abstractions/下提供了大量现成的抽象规则，比如abstractions/nginx、abstractions/openssl等，编写策略时应优先复用这些抽象，而不是从零开始逐条罗列。
利用学习模式生成和调优策略
手动写profile容易遗漏权限，AppArmor提供了基于行为的策略生成工具aa-genprof。它的工作流程是：启动监听后，你正常使用目标程序，让内核记录它实际访问了哪些资源，随后工具根据日志自动生成规则。操作示例如下：
# 生成新策略，程序执行期间照常使用它 sudo aa-genprof /usr/bin/myapp # 另开终端，运行并充分使用目标程序 /usr/bin/myapp # 对已有策略追加规则，分析新产生的日志 sudo aa-logprof /usr/bin/myapp
aa-logprof会逐条展示日志中发现的新访问请求，并给出建议规则，你可以选择允许、允许并引入抽象规则、继承子profile或拒绝。整个交互过程本质上就是把学习期的行为转化为白名单。
推荐的上线节奏是三步走：第一阶段用complain模式部署，让程序在只记录不拦截的状态下运行足够长的时间，覆盖各种业务场景；第二阶段分析日志确认没有误拦截风险后，切换到enforce；第三阶段在enforce下持续观察，出现DENIED时用aa-logprof迭代修正。切换命令很简单：
# 切换到学习模式 sudo aa-complain /etc/apparmor.d/usr.bin.myapp # 切换到强制模式 sudo aa-enforce /etc/apparmor.d/usr.bin.myapp
需要特别提醒的是，生产环境中不要一上来就直接enforce，尤其是数据库、Web服务等复杂程序，遗漏一条关键写权限就可能导致服务启动失败。同时建议为关键目录添加显式的deny规则作为兜底，比如deny对/etc/shadow、/root/**的写操作，这样即便主规则写得不严谨，最敏感的数据也有第二道防线。通过循序渐进的策略打磨，AppArmor能够在openSUSE上构建起细粒度、可审计的进程级安全边界，为服务器和桌面环境都提供坚实的防护。
AppArmor配置openSUSE安全强制访问控制修改时间：2026-09-01 14:58:42