SELinux如何与AppArmor比较

时间2026-01-16 20:39:04发布访客分类主机资讯浏览715

导读：SELinux 与 AppArmor 对比核心差异一览维度 SELinux AppArmor 安全模型与粒度基于**安全标签（上下文）**的系统级 MAC，细粒度强约束基于路径的应用级 MAC，规则直观默认发行版...

SELinux 与 AppArmor 对比

核心差异一览

维度	SELinux	AppArmor
安全模型与粒度	基于安全标签（上下文）的系统级 MAC，细粒度强约束	基于路径的应用级 MAC，规则直观
默认发行版	RHEL、Fedora、CentOS 默认启用	Ubuntu、openSUSE 默认启用
策略形式	策略/类型强制（TE），规则需编译为策略模块	文本配置文件，无需编译
模式	Enforcing / Permissive / Disabled	Enforce / Complain
文件系统依赖	需要支持扩展属性（xattrs）以存储标签	对文件系统无特殊要求
典型侧重点	系统级最小权限、跨进程/跨容器一致边界	快速为关键应用（如 Nginx、MySQL）上“安全带”
容器生态	提供容器标签与隔离能力（如 MCS/MLS）	Docker 可用默认 docker-default 或自定义 profile
学习与排障	学习曲线陡峭，依赖日志与工具（如 audit2allow）	学习曲线平缓，aa-status/aa-logprof 等工具易上手
典型命令	getenforce、setenforce、sestatus、semanage、audit2allow	aa-status、aa-enforce、aa-complain、apparmor_parser
以上对比要点来自对两者在模型、发行版默认、策略形式、模式、文件系统依赖、容器支持与运维工具的综合梳理。

工作原理简述

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）定位拒绝事件并迭代策略。

声明：本文内容由网友自发贡献，本站不承担相应法律责任。对本内容有异议或投诉，请联系2913721942#qq.com核实处理，我们将尽快回复您，谢谢合作！