SELinux如何与AppArmor比较

SELinux 与 AppArmor 对比

核心差异一览

工作原理简述

• SELinux：为系统中的主体（进程）与客体（文件、端口、进程间通信等）打上安全上下文标签，访问是否被允许由策略决策引擎按标签与权限矩阵判定；即使 root 也无法绕过，除非关闭或放宽策略。常见运行模式为 Enforcing/Permissive/Disabled，并提供如 audit2allow 等工具将审计日志转化为策略模块以迭代收敛。
• AppArmor：为每个关键进程加载文本配置文件（位于 /etc/apparmor.d/），以路径与 Linux capabilities 为核心声明允许的动作；支持 Enforce/Complain 两种模式，Complain 仅告警不阻断，便于“学习/生成”策略；常用命令包括 aa-status、aa-enforce、aa-complain、apparmor_parser。

如何选择与落地

• 倾向选择 SELinux 的场景
  • 需要系统级、跨服务一致的最小权限边界，或存在多租户/高合规要求（如政府、金融）。
  • 可接受更陡峭的学习曲线与更严格的策略治理，愿意投入标签管理与策略编译维护。
• 倾向选择 AppArmor 的场景
  • 追求快速落地与低运维成本，优先为关键应用（如 Nginx、MySQL）加约束。
  • 运行环境复杂或文件系统不支持 xattrs，希望以路径为中心快速编写与调试策略。
• 容器场景
  • AppArmor：Docker 默认提供 docker-default 配置，可用 –security-opt apparmor= 应用自定义 profile，限制容器内对敏感目录（如 /etc）的写入，即使以 root 运行也受限。
  • SELinux：通过容器标签与 MCS/MLS 提供进程/容器间隔离，适合强隔离需求；两者通常只启用其一，以发行版默认为准。

快速上手与排障命令

• SELinux
  • 查看与切换：getenforce、setenforce 0|1；查看状态：sestatus
  • 策略与日志：semanage（用户/端口/布尔管理）、audit2allow（从拒绝日志生成策略模块）
• AppArmor
  • 状态与模式：aa-status；aa-enforce|aa-complain <path|profile>
  • 加载与调试：apparmor_parser -r /etc/apparmor.d/；结合系统日志（如 /var/log/syslog 或 /var/log/audit/audit.log）定位拒绝事件并迭代策略。