当前位置：首页 > news >正文

AppArmor与SELinux核心区别解析

news 2026/7/9 6:10:24

AppArmor 和 SELinux 都是 Linux 内核中的强制访问控制（MAC）安全模块，旨在为系统提供超越传统自主访问控制（DAC）的更细粒度的安全防护。它们都遵循“默认拒绝，明确允许”的原则，但两者在设计哲学、实现机制、易用性和适用场景上存在显著差异。

一、核心设计哲学与模型对比

两者的根本区别在于其安全模型的构建方式。

特性	AppArmor	SELinux
安全模型	路径/名称基于 (Path-based / Name-based)	类型强制与多级安全 (Type Enforcement & MLS)
核心思想	为具体的应用程序（程序文件）定义其可以访问的资源路径。策略与二进制文件的路径绑定。	为系统中的所有主体（进程）和客体（文件、端口等）分配安全上下文（标签），策略基于这些标签间的访问规则。
类比	白名单监狱：为每个重要的程序建造一个独立的“监狱”（Profile），明确规定它只能接触“监狱”内的特定物品（文件路径、网络端口等）。	彩色标签系统：给系统中的每个进程和资源都贴上带有颜色和属性的标签，规则规定了“红色标签的进程”只能访问“蓝色标签的文件”。

二、技术实现机制详解

基于不同的模型，两者的实现方式也迥然不同。

策略定义与关联方式

AppArmor：策略（Profile）以文本文件形式存储在/etc/apparmor.d/目录下，文件名通常与二进制文件的绝对路径相关（如/usr/sbin/sshd对应usr.sbin.sshd）。策略内容直接使用文件系统路径来定义允许或拒绝的访问。
```
# AppArmor 策略示例 (sshd) profile sshd /usr/sbin/sshd { /etc/ssh/* r, # 允许读取 /etc/ssh/ 下的文件 /var/run/sshd.pid kwl, # 允许锁定PID文件 network inet tcp, # 允许IPv4 TCP deny /etc/shadow w, # 明确拒绝写入shadow文件 }
```

SELinux：策略是编译后的二进制文件。每个文件、进程、端口等客体都拥有一个扩展属性存储的安全上下文，格式为user:role:type:level（如system_u:object_r:ssh_key_t:s0）。策略规则定义了源类型（进程）对目标类型（文件）的访问向量（权限）是否允许。

# 查看文件安全上下文 $ ls -Z /etc/shadow system_u:object_r:shadow_t:s0 /etc/shadow # 查看进程安全上下文 $ ps -eZ | grep sshd system_u:system_r:sshd_t:s0-s0:c0.c1023 1234 ? 00:00:00 sshd # SELinux 策略规则逻辑（简化表示） # allow sshd_t shadow_t : file { read getattr }; # 上述规则表示：类型为 `sshd_t` 的进程允许对类型为 `shadow_t` 的文件执行 `read` 和 `getattr` 操作。

策略生成与管理的易用性
- AppArmor：以其易用性著称。它提供了aa-genprof和aa-logprof等工具，可以在“投诉模式”下运行程序，自动分析日志并交互式地帮助管理员生成策略。这使得为非复杂应用创建基本策略变得相对简单。
- SELinux：学习曲线陡峭。策略编写复杂，通常需要了解安全上下文、类型、属性、角色等概念。虽然也有类似audit2allow的工具可以根据拒绝日志生成策略模块，但生成的规则可能过于宽泛，需要人工精炼。策略管理涉及semanage,restorecon,chcon等一系列命令。
默认配置与发行版支持
- AppArmor：是Ubuntu、Debian、openSUSE等发行版的默认 MAC 系统。这些发行版为许多核心软件包（如 Apache, MySQL）预装了维护良好的策略配置文件。
- SELinux：是Red Hat Enterprise Linux (RHEL)、CentOS、Fedora、Rocky Linux等 Red Hat 系发行版的默认 MAC 系统。其策略在默认安装时即处于“强制”模式，为系统提供了开箱即用的深度防护。

三、功能特性深度对比

对比维度	AppArmor	SELinux	分析与总结
粒度与灵活性	中等。控制到应用程序和文件路径级别。对于动态创建文件或使用硬链接的场景，路径规则可能不够灵活。	极高。控制到进程类型和文件类型级别，与路径无关。即使文件被移动，其安全标签保持不变，策略依然有效。更适合复杂、动态的环境。	SELinux 的标签系统提供了更抽象、更稳固的安全控制。
网络控制	支持基本的网络协议（inet, inet6）和套接字类型（stream, dgram）控制。	支持更细粒度的网络控制，可以基于端口类型、网络接口类型、节点类型等制定策略。	SELinux 在网络层面的策略能力更强。
多级安全(MLS)	不支持。无法实现基于数据分类（如“机密”、“秘密”）的强制访问控制。	支持。是其核心特性之一，能够定义安全级别（s0, s1, s2...）和范畴，满足军用或政府级的高安全性需求。	这是 SELinux 用于高 Assurance 等级系统的关键特性。
对现有系统影响	较小。策略仅应用于显式配置了的程序，其他所有程序仍按原有 DAC 规则运行。部署可以逐步进行。	较大。默认情况下，所有进程和文件都处于全局策略管控下。错误的标签或策略可能导致服务故障，需要更全面的理解才能有效管理。	AppArmor 的增量部署方式更友好。
性能开销	通常较低。策略匹配基于路径，查询相对直接。	在极端复杂策略下可能稍高，因为需要查询安全服务器进行上下文匹配。但对于现代服务器硬件，两者在合理配置下的开销都可忽略不计。	日常使用中差异不明显。

四、典型应用场景与选择建议

场景	推荐选择	理由
Web服务器/数据库快速加固	AppArmor	目标明确（保护 Nginx, Apache, MySQL），使用`aa-logprof`可以快速生成有效策略，管理直观。
桌面系统或开发者工作站	AppArmor	对用户透明性更高，不易因策略问题阻断自定义或开发工作流。例如，Ubuntu 使用 AppArmor 来沙箱化 Snap 应用。
遵循严格合规性要求（如 STIG, FIPS）	SELinux	特别是在 RHEL 环境中，许多安全基线（如 DISA STIG）直接要求并配置 SELinux。其 MLS 特性是满足某些高级别合规要求的必要条件。
构建多租户或高度隔离的环境	SELinux	其基于类型的强制隔离能力更强，能够更清晰地定义安全边界，防止权限跨越不同服务或用户域。
现有系统技术栈	跟随发行版	如果系统已是 RHEL/CentOS，则深入学习和配置 SELinux 是更自然和获得更好支持的选择。反之，在 Ubuntu/Debian 上启用和配置 SELinux 则充满挑战且社区支持较弱。

五、配置与管理命令速查表

操作	AppArmor命令示例	SELinux命令示例
查看状态	`sudo aa-status`	`getenforce`(查看模式：Enforcing/Permissive/Disabled) `sestatus`(查看详细信息)
更改模式	`sudo aa-complain /path/to/binary`(投诉) `sudo aa-enforce /path/to/binary`(强制)	`setenforce 0`(设为 Permissive) `setenforce 1`(设为 Enforcing) (需修改`/etc/selinux/config`永久生效)
分析日志生成策略	`sudo aa-logprof`(交互式分析)	`sudo ausearch -m avc -ts recent \| audit2allow -a`(生成允许规则) `sudo ausearch -m avc -ts recent \| audit2allow -a -M mypol && semodule -i mypol.pp`(生成并安装模块)
管理策略文件	编辑`/etc/apparmor.d/`下的文件，然后`sudo apparmor_parser -r /path/to/profile`重载	编译模块：`checkmodule -M -m -o mymod.mod mymod.te` `semodule_package -o mymod.pp -m mymod.mod` 安装：`sudo semodule -i mymod.pp`
修复文件上下文	不适用（基于路径）	`restorecon -Rv /path/to/file`(恢复默认标签) `chcon -t httpd_sys_content_t /var/www/html/index.html`(临时修改标签)
查看/修改布尔值	无直接对应概念	`getsebool -a`(列出所有) `setsebool -P httpd_can_network_connect on`(永久开启一个布尔值)