Ubuntu 中 SELinux 与 AppArmor 的差异与选型
概览与定位
- SELinux 与 AppArmor 都是 Linux 内核的 强制访问控制（MAC） 机制，但设计哲学与实现路径不同。
- Ubuntu 默认集成并启用 AppArmor；SELinux 常见于 RHEL、Fedora、CentOS 等发行版。
- SELinux 由 NSA 与 SCC 发起，2000 年开源、2003 年并入上游内核；AppArmor 则以“为应用绑定配置文件、路径白名单式管控”见长。
核心差异对比
| 维度 |
AppArmor |
SELinux |
| 控制模型 |
基于路径的访问控制，按可执行程序绑定配置文件（白名单） |
基于安全标签（用户:角色:类型:级别），以**类型强制（TE）**为核心 |
| 默认与生态 |
Ubuntu 默认启用；openSUSE 亦默认；预置大量服务 profile |
RHEL/Fedora/CentOS 默认启用；提供 targeted / MLS 等策略 |
| 文件系统依赖 |
对文件系统无扩展属性依赖，部署与迁移更省心 |
需要支持扩展属性（xattrs）与正确的标签管理 |
| 策略编写与维护 |
规则无需编译，语法直观；有 aa-genprof / aa-logprof 辅助生成与调优 |
规则以 TE/策略模块 为主，常借助 audit2allow / semodule 编译与加载 |
| 模式与日志 |
两种模式：enforce（阻断违规）/ complain（仅告警，便于“学习”） |
三种模式：enforcing / permissive / disabled；拒绝会记录 avc: denied |
| 安全边界与绕过 |
路径可被重命名/移动而失效，边界相对更“弱”但易用 |
标签与 inode 绑定更稳固，对复杂场景的细粒度控制更强 |
| 典型命令 |
aa-status / aa-enforce / aa-complain / systemctl reload apparmor |
getenforce / setenforce / sestatus / semanage / audit2allow / semodule |
在 Ubuntu 的默认状态与基本操作
- 查看与切换 AppArmor
- 查看状态：sudo apparmor_status
- 切换模式：sudo aa-enforce /usr/sbin/nginx，sudo aa-complain /usr/sbin/nginx
- 重新加载：sudo systemctl reload apparmor
- 发现未受限进程：sudo aa-unconfined
- 查看与切换 SELinux（若已安装启用）
- 查看状态：getenforce / sestatus
- 临时切换：setenforce 0|1（Permissive/Enforcing）
- 策略与日志：semanage / audit2allow / semodule；拒绝日志常见为 /var/log/messages 中的 avc: denied。
选型建议
- 追求开箱即用、运维成本低、以服务为边界的“够用安全”：优先 AppArmor（Ubuntu 原生支持、规则直观、complain 模式便于生成与调试）。
- 需要更强的细粒度与体系化策略、面向多用户/多域/复杂合规场景：倾向 SELinux（标签体系与类型强制更强，但学习与管理成本更高）。
- 无论选择哪种，建议先在 Permissive/Complain 模式完成观察与调优，再切至 Enforcing 模式上线。
