AppArmor.

AppArmor 是一种 Linux Security Module (LSM),它通过以文件路径、capabilities 和网络原语表达的、面向每个程序的配置文件来实施强制访问控制,而非 SELinux 所用的 inode 标签。它源自 Immunix,由 SUSE 与 Canonical 维护,自 2000 年代后期起成为 Ubuntu 与 openSUSE 默认的 MAC 框架,并自内核版本 2.6.36 起进入主线内核。配置文件位于 /etc/apparmor.d,可加载为 enforce 模式或 complain(仅记录)模式,并配套 aa-genprof、aa-logprof、aa-easyprof 等辅助工具。其基于路径的设计通常比 SELinux 策略更易编写与审计,代价是对重命名、bind mount 与 chroot 的语义较弱。

在容器中,除非通过 --security-opt apparmor= 覆盖,否则 Docker 会为每个容器在 enforce 模式下生成并将 docker-default 配置文件加载到 tmpfs;它会阻止对 /proc/sysrq-trigger、/sys 等敏感路径的写入,并与 seccomp 和已剥离的 capabilities 协同构成纵深防御。AppArmor 还被 snapd、libvirt、LXD 和 Firefox 使用。它的局限是实实在在的:由于规则匹配的是路径而非底层对象,硬链接与挂载技巧有时能绕过某个配置文件,而一个配置文件的优劣取决于其规则——过于宽泛的通配符(例如允许 /** rwk)会让其失去意义。CVE-2019-5736(runc 宿主机二进制覆写)表明,容器逃逸可能发生在默认配置文件未覆盖的区域,因此 AppArmor 会与 seccomp、用户命名空间和只读挂载叠加使用,而不是单独依赖它。

flowchart TB
  P[进程执行] --> K[内核 LSM 钩子]
  K --> Q{配置文件已加载?}
  Q -- No --> U[未受限:普通 DAC]
  Q -- Yes --> M{操作在配置文件中?}
  M -- enforce 模式 --> R{是否允许?}
  R -- Yes --> A[允许]
  R -- No --> D[拒绝 + 审计日志]
  M -- complain 模式 --> L[允许 + 记录违规]

典型的工作流程是先在 complain 模式下运行新的配置文件,实际使用一遍该应用,再用 aa-logprof 将记录到的访问转换为规则,然后切换到 enforce 模式。