AppArmor 自定义权限怎么写到 local 目录避免升级被覆盖

如果一个 Ubuntu 软件包已经提供了 AppArmor profile，而业务只需要额外放行一个站点目录，长期直接改主 profile 并不稳妥：包升级可能带来 conffile 冲突，甚至让手工规则被覆盖。更适合的做法是先看主 profile 是否包含 #include ，再把自定义权限放进 /etc/apparmor.d/local/ 对应文件，最后重载目标 profile。

官方文档：https://documentation.ubuntu.com/server/how-to/security/apparmor/

local 目录不是另一套独立 profile，而是主 profile 预留的本地 include 入口。文件名必须和 include 对应，规则仍然要保持最小权限，修改后也必须重新加载 profile。

为什么不直接改包提供的 profile

AppArmor 的规则文件通常位于 /etc/apparmor.d/，软件包负责维护其中一部分内容。直接改主文件当然能立即表达权限，但升级时包管理器需要处理维护者版本与本地版本的差异，结果可能是弹出冲突提示，或者在特定更新策略下丢失本地改动。

Ubuntu 文档把本地覆盖作为单独的维护路径：/etc/apparmor.d/local/ 下的文件用于保存针对特殊部署的额外规则。这样做的关键不是“绕过” AppArmor，而是把包的默认策略和站点自己的增量策略分开，后续更容易看出谁负责哪一部分。

先确认主 profile 的 include 入口

先根据被限制的可执行文件找到主 profile。例如目标程序是一个名为 usr.sbin.demo 的服务，主文件通常是 /etc/apparmor.d/usr.sbin.demo。不要直接猜 local 文件名，先在主文件里查找已有的本地 include：

# 中文注释：先确认主 profile 是否已经预留 local include
sudo grep -nE '#include[[:space:]]*

常见入口类似 #include 。尖括号里的路径对应 /etc/apparmor.d/local/usr.sbin.demo，不是随便起一个同名相近的文件。如果主 profile 没有这一行，就需要在正确的 profile 块中补上 include；不要把规则孤零零地放进 local 目录后期待它自动生效。

把最小权限写进对应的 local 文件

确认入口后，只在 local 文件里添加业务真正需要的路径规则。下面示例假设服务需要读取渲染缓存，并向自己的输出目录写入文件；路径只是示例，部署时应替换为实际目录，并先判断是否确实需要写权限。

# 中文注释：创建 AppArmor 约定的本地覆盖目录
sudo install -d -m 0755 /etc/apparmor.d/local

# 中文注释：文件名必须与主 profile 中的 local include 完全对应
sudo tee /etc/apparmor.d/local/usr.sbin.demo >/dev/null 

AppArmor 路径规则的权限字母要和任务匹配：只读场景用 r，需要创建或修改文件时才考虑 rw。不要为了消除一次拒绝日志就把目录扩大到 /**，也不要把网络、能力或执行权限混在这篇路径覆盖示例里；它们应当根据具体审计记录单独判断。

重载 profile，并留好升级后的复查动作

保存 local 文件后，主 profile 不会因为文件落盘就自动改变内核中的已加载策略。可以重载单个 profile，也可以按维护窗口重载 AppArmor 服务：

# 中文注释：重载单个 profile，让主文件和 local include 一起重新解析
sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.demo

# 中文注释：查看目标 profile 是否仍处于预期的 enforce 或 complain 状态
sudo apparmor_status | grep -F 'usr.sbin.demo' || true

如果程序仍然被拒绝，先看审计记录里的 profile、operation 和 name，确认命中的确实是这个 profile 与目标路径；不要只看进程名就继续放宽规则。Ubuntu 文档也提醒，编辑 profile 后需要重新加载，apparmor_parser -r 是针对单个文件的直接动作。

升级后要把复查当成维护动作，而不是再次直接编辑包文件：确认主 profile 的 local include 仍存在，检查 local 文件没有被删除，再按需重载。可以保留一份站点配置管理中的期望内容，使用差异比较发现入口变化；若包升级重构了 profile 名称，先调整 include 对应关系，再重新评估每条权限。

几个容易踩到的边界

• local 文件没有自动生效：没有主 profile 的 include，文件只是在磁盘上存在。
• 文件名不对应：local/usr.sbin.demo 只能被对应的 #include 引入。
• 规则过宽：先放行具体目录和所需权限，避免用大范围通配符掩盖真实访问需求。
• 只改文件不重载：磁盘内容更新不等于已加载策略更新，重载后再观察审计记录。

相关问题

local 目录能不能放一个自定义完整 profile？它更适合保存由主 profile 引入的本地增量规则，不应把它当成任意 profile 仓库；完整 profile 是否能独立加载，要按 AppArmor 的 profile 结构和部署方式单独设计。

升级后权限又失效怎么办？先确认包升级是否改了主 profile 文件名、profile 块或 local include，再查看 local 文件是否仍在，最后重新加载并根据新的拒绝记录收敛规则。

总结一下：主 profile 负责包提供的基础策略，/etc/apparmor.d/local/ 负责站点增量规则。先确认 include，再写最小权限，重载后按 profile 和路径复查；这样既能保留安全边界，也能降低升级时与包维护文件正面冲突的概率。