用 AppArmor 为程序建立访问边界：策略、日志与安全调试-未完纪

原作者：Canonical / Ubuntu Server documentation contributors。本文依据 Ubuntu Server 官方《AppArmor》全文翻译整理，核对日期为 2026 年 10 月 5 日。原页没有明确首次发表日期，页面显示的 2026 年 7 月 2 日是更新日期。中文校注与原文区分标明。

AppArmor 是 Linux 安全模块的一种实现。它按程序定义 profile（下文称“策略”），限制应用能访问的文件和使用的权限，在传统 UNIX 自主访问控制（DAC）之外，再增加强制访问控制（MAC）。两层检查共同起作用：策略允许的操作，仍需符合文件权限等其他安全约束。

Ubuntu 默认安装并加载 AppArmor。先用 aa-status 查看实际状态，不要把“安装了软件包”当作“目标程序已受策略约束”的证据。部分软件包自带策略，另有策略可通过 apparmor-profiles 包获得。

未完纪绘制：从访问请求到策略修订的流程示意，非真实系统截图。

安装策略并认识两种模式

sudo apt install apparmor-profiles

策略主要有两种工作模式。complain（学习、投诉模式）用于开发和调试：通常记录没有获准的访问，而不据此阻断。enforce（强制、受限模式）执行策略并记录违反策略的行为。

校注：学习模式应只用于范围明确、时间有限的调试；它不能证明策略已经提供强制保护，也不等于绕过 UNIX 权限或其他安全机制。Ubuntu 24.04 的 aa-complain 手册明确说明，显式 deny 规则在学习模式下仍会执行，因此不能将“学习模式放行”理解为整个系统无条件允许。

查看、切换与重新加载策略

可选的 apparmor-utils 包提供状态查询、切换模式和生成策略等命令。策略文件保存在 /etc/apparmor.d。该目录还包含可复用的 abstractions，例如 abstractions/base 会允许许多共享库、journal 日志写入、若干伪设备、接收非受限进程的信号等行为。引用一个抽象文件，就同时接受了它包含的权限，审查时也要查看被包含文件。

目的	命令	影响
查看状态	`sudo apparmor_status`	检查已加载策略及模式
进入学习模式	`sudo aa-complain /path/to/bin`	降低指定程序的策略约束
进入强制模式	`sudo aa-enforce /path/to/bin`	恢复执行指定策略
重载一份策略	`sudo apparmor_parser -r /etc/apparmor.d/profile.name`	让修改后的规则生效
重载全部策略	`sudo systemctl reload apparmor.service`	影响范围更广

其中 /path/to/bin 是实际可执行文件路径，profile.name 是实际策略文件名。原文用 /bin/ping 举例；现代系统的路径、符号链接和发行版打包方式可能不同，应先检查本机文件和已加载策略，不可直接把示例名当作目标名。修改策略文件后必须重新加载，磁盘文件与内核当前规则不是同一份状态。

禁用或恢复单份策略

原文给出通过 /etc/apparmor.d/disable 中的符号链接标记禁用，并从内核移除该策略的方法。下面是原文操作的保留示例，适合解释机制；会实际降低防护，本文未执行。

sudo ln -s /etc/apparmor.d/profile.name /etc/apparmor.d/disable/
sudo apparmor_parser -R /etc/apparmor.d/profile.name

恢复时，只移除对应的禁用符号链接，然后重新加载该策略：

sudo rm /etc/apparmor.d/disable/profile.name
cat /etc/apparmor.d/profile.name | sudo apparmor_parser -a

校注：原文的 rm 针对一条确定的符号链接，不应改成通配符或递归删除。操作前确认路径、文件类型以及将受影响的程序，保留原策略副本和恢复命令。加载后重新检查状态和业务行为；单纯命令返回成功并不能证明全部进程都受预期策略约束。

读懂一份策略

策略是普通文本。传统策略文件名通常将可执行文件完整路径中的 / 换成 .，例如 /bin/ping 对应 /etc/apparmor.d/bin.ping。原文介绍两类主要规则：路径规则控制程序可访问的文件，capability 规则控制受限进程可使用的特权。下面保留原文的教学策略：

#include <tunables/global>
/bin/ping flags=(complain) {
  #include <abstractions/base>
  #include <abstractions/consoles>
  #include <abstractions/nameservice>

  capability net_raw,
  capability setuid,
  network inet raw,

  /bin/ping mixr,
  /etc/modules.conf r,
}

#include <tunables/global> 引入公共定义，让多个策略复用变量或规则。
/bin/ping flags=(complain) 指定程序路径，并在此示例中使用学习模式。
capability net_raw, 允许使用 CAP_NET_RAW；示例还列出 setuid 与原始 IPv4 网络权限。
/bin/ping mixr, 包含读取、可执行映射及继承当前约束的执行权限；原文仅概括为读取和执行。/etc/modules.conf r, 只授予读取。

版本与最小权限校注：这是一份解释语法的历史示例，不能作为所有现代 ping 的生产策略。实际所需能力、可执行路径、配置文件和网络规则应按目标系统核对。不要因示例列出 setuid 就给其他程序照样增加该能力。

创建与更新策略

开始生成策略前，先设计测试计划。将应用行为拆成小用例，每个用例写明目的和操作步骤。原文建议至少覆盖启动、停止、重新加载以及 init 脚本支持的各条命令；采用 systemd 的服务还应据此覆盖本项目实际使用的管理动作。对文件读写、网络、定时任务和异常路径，也应根据应用真实行为安排用例。

用 aa-genprof 创建新策略：

sudo aa-genprof executable
# 原文以 slapd 为例：
sudo aa-genprof slapd

若希望将策略贡献给上游，可以向 Launchpad 的 AppArmor 软件包提交问题，附上新策略、测试计划及测试用例。生成工具只观察被执行到的路径；未覆盖的行为不会自动获得正确规则。

程序出现异常时，审计消息会进入日志。aa-logprof 能扫描日志中的 AppArmor 审计消息，供管理员逐项审查并更新策略：

sudo aa-logprof

不要机械批准每一条建议。一次被拒绝的访问可能是正常功能，也可能是错误配置或异常输入；先确认业务是否需要，再授予尽可能窄的路径与权限。

现成的实验策略

原文提到 apport-profiles 和 apparmor-profiles-extra 中的实验策略，并说明它们通常不能开箱即用。由于尚不够成熟，部分策略以学习模式分发，供用户选择、测试和改进。更实验性的文件还可能位于 /usr/share/doc/apparmor-profiles/extras/。

校注：上面的软件包拼写按当前原页保留，其中 apport-profiles 与本页主包名 apparmor-profiles 不一致。本文未核验每个 Ubuntu 版本的软件包仓库，不能据此保证该名称在本机可安装；应先查询发行版包索引。实验策略可作为起点，不代表已经满足本项目的权限边界。

从拒绝日志找到问题

因“规则未允许”而产生的拒绝，通常能在 dmesg 或收集内核消息的日志中看到。原文提醒，显式 deny 规则默认可能不产生对应的拒绝日志，所以“日志中没看到”不是“没有拒绝”的充分证据。

[1521056.552037] audit: type=1400 audit(1571868402.378:24425): apparmor="DENIED" operation="open" profile="/usr/sbin/cups-browsed" name="/var/lib/libvirt/dnsmasq/" pid=1128 comm="cups-browsed" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[1482106.651527] audit: type=1400 audit(1571829452.330:24323): apparmor="DENIED" operation="sendmsg" profile="snap.lxd.lxc" pid=24115 comm="lxc" laddr=10.7.0.69 lport=48796 faddr=10.7.0.231 fport=445 family="inet" sock_type="stream" protocol=6 requested_mask="send" denied_mask="send"

以上是原文历史日志，不是本文执行结果。消息通常包含时间戳、audit 标记及 apparmor="DENIED" 分类，后续字段说明谁、在什么策略下、尝试了什么。

第一条的 operation="open" 表示打开文件；profile 指向受约束的 /usr/sbin/cups-browsed；name 是目标目录。pid、comm 标识触发程序，requested_mask、denied_mask、fsuid、ouid 提供访问权限和身份信息。
原文将这份策略的文件名写成 /etc/apparmor.d/usr.bin.cups-browsed，与日志中的 /usr/sbin 不一致。按本页的命名规则应先查 usr.sbin.cups-browsed，再以系统实际加载来源为准；这里明确标注该处原文疑误。
第二条的 sendmsg 是网络发送；snap.lxd.lxc 属于 Snap 策略，原文指出其位置为 /var/lib/snapd/apparmor/profiles/snap.lxd.lxc。本地和远端地址、端口、地址族、套接字类型及协议字段用于还原发送操作。

据此定位目标策略和具体动作，再决定是修正应用配置、调查异常，还是增加必要规则。IP 地址与进程号只属于原文示例，不应当作本机目标。

怎样保留本地定制

安全策略不能过宽，但特殊部署确实可能需要增加一项访问。原文比较三种方法：

直接改策略文件。最直接，但 /etc 下的软件包配置文件会受到升级流程影响，可能出现配置冲突提示；某些升级策略也可能覆盖本地规则。
使用 tunables。例如在 /etc/apparmor.d/tunables/home 定义额外主目录路径。变量只影响实际引用它的策略，而且共享变量变更可能同时影响多份策略。
使用 local include。/etc/apparmor.d/local/ 中的本地文件用于部分软件包的特定部署调整，减少直接修改打包策略造成的升级冲突。它是否生效，取决于主策略是否包含该文件。

完成修改后重载策略，并重新运行前述测试计划。权限授予应对应明确业务需要，不能为了消除日志而给出过宽的通配路径。

完全禁用与恢复 AppArmor

高影响操作：原文指出，Ubuntu 24.04 LTS 及以后版本中，仅停止服务不能完全关闭 AppArmor。完全禁用需要修改内核启动参数；这会降低整台系统的安全性，并涉及重新启动。下列说明保留原文完整边界，绝非解决单个拒绝问题的默认建议。

编辑 /etc/default/grub，在 GRUB_CMDLINE_LINUX 内加入 apparmor=0，保留其他既有参数。
运行 sudo update-grub 更新引导配置。
在具备维护窗口与恢复通道的条件下重新启动系统。

原文给出的禁用后状态示例：

sudo aa-status

apparmor module is loaded.
apparmor filesystem is not mounted.

systemctl status apparmor

○ apparmor.service - Load AppArmor profiles
   Loaded: loaded (/usr/lib/systemd/system/apparmor.service; enabled; preset: enabled)
   Active: inactive (dead)
Condition: start condition unmet
           └─ ConditionSecurity=apparmor was not met

这里保留了状态的关键字段，省略原日志中与机制无关的具体时间、主机名和文档提示。它描述的是原文示例，不能据此断言你的主机状态。

重新启用时，移除 GRUB_CMDLINE_LINUX 中的 apparmor=0，再次执行 sudo update-grub 并重启，然后用 sudo aa-status 检查。原页展示的启用结果含 119 profiles are loaded、24 profiles are in enforce mode 和 /usr/bin/man；数量随系统而变，不是验收标准。

继续阅读与本文审核范围

原文还推荐 AppArmor Administration Guide、Ubuntu 社区 AppArmor Wiki、openSUSE AppArmor 和 Debian AppArmor Wiki。需要 Ubuntu Server 社区帮助时，可从原页的 Matrix #server 与 #security 链接进入。旧指南可能面向不同发行版，应核对适用版本。

本文只做源文核对和静态审查，没有安装软件、重载策略、停用防护、改引导参数或重启机器。重点检查了权限扩大、示例路径、包名和日志解释；未发现硬编码秘密或远程命令注入链，不代表目标策略或系统不存在漏洞。要验证实际行为，仍需在隔离测试机上覆盖正常与拒绝场景。

文章版权归作者所有，未经允许请勿转载。

THE END