SELinux 与 AppArmor：哪种 MAC 框架适合您的服务器？

SELinux 和 AppArmor 都在 Linux 上实施强制访问控制（MAC），即使进程获得了 root 权限，也能限制其操作范围。两者的区别在于实现方式：SELinux 为每个文件和进程分配持久的标签，而 AppArmor 则采用文件路径规则。这一设计选择决定了其他一切：复杂性、安全深度，以及各发行版默认搭载的工具。

SELinux 的工作原理

SELinux最初由美国国家安全局（NSA）开发，并作为默认组件预装在RHEL、CentOS、Fedora和Rocky Linux系统中。它会为系统中的每个对象（包括文件、进程、端口和套接字）分配一个安全上下文，格式为 user:role:type:level。 type 字段通过一种称为“类型强制（TE）”的机制承担了大部分核心工作。

例如，Apache Web 服务器以 httpd_t。Web 内容文件则具有不同的类型。如果没有任何策略规则明确允许 httpd_t 访问该内容类型，则请求将被拒绝。这是一种“默认拒绝”模型。除非规则另有规定，否则一切均被禁止。

SELinux 还支持多级安全（MLS）和多类别安全（MCS），它们根据敏感级别对数据进行分类，并据此限制访问。正是 MCS 赋予了 SELinux 强大的容器隔离能力，使容器彼此隔离，并与主机隔离。这在 Kubernetes 和 OpenShift 环境中尤为重要，因为在这些环境中，Pod 共享同一节点。

其代价是复杂性。SELinux 学习曲线陡峭。排查访问拒绝问题需要阅读审计日志、理解安全上下文，有时还需使用 audit2allow。对于没有专职安全人员的团队而言，这种额外负担是切实存在的。

AppArmor 的工作原理

AppArmor 采用了一种不同的方法。它不采用对象标记的方式，而是根据应用程序的文件路径为其附加安全配置文件。例如，针对 /usr/sbin/nginx 定义了 Nginx 可以读取哪些目录、可以绑定哪些端口，以及需要哪些权限。配置文件是存储在 /etc/apparmor.d/.

AppArmor是Ubuntu、Debian和SUSE系统上的默认MAC框架，自Linux内核2.6.36版本起便已集成其中。未配置配置文件的应用程序将回退至标准的Linux DAC权限。

AppArmor 针对每个配置文件提供两种运行模式：强制模式（阻止违规并记录日志）和警告模式（仅记录违规而不阻止）。这使得逐步部署新配置文件成为可能。建议先以警告模式运行，审查日志，收紧配置文件，然后切换到强制模式。

诸如 aa-genprof 和 aa-logprof 等工具可通过观察应用程序的行为并据此生成规则，从而交互式地构建配置文件。与 SELinux 策略模块相比，其语法更易于阅读和手动编辑。

其缺点在于，基于路径的规则无法跟随文件移动。理论上，硬链接或绑定挂载可以绕过基于路径的限制。此外，AppArmor 缺乏原生的 MLS/MCS 支持，因此它虽能将容器与主机隔离，但无法像 SELinux 那样实现容器之间的相互隔离。

并列对比

基本配置

SELinux

检查当前状态：

sestatus
getenforce

以“Permissive”模式启动，以便记录违规行为而不阻断任何服务：

setenforce 0

对大多数服务器使用“targeted”策略。该策略会限制Web服务器和数据库等高风险服务，同时对其他服务不作限制。在 /etc/selinux/config:

SELINUX=enforcing
SELINUXTYPE=targeted

检查文件和进程的安全上下文：

ls -Z /var/www/html
ps -eZ | grep httpd

如果某项服务使用非标准端口，请更新策略：

semanage port -a -t ssh_port_t -p tcp 9999

对于导致访问被拒绝的自定义应用程序，请根据审计日志创建策略模块：

ausearch -m avc -ts recent | audit2allow -M my_custom_policy
semodule -i my_custom_policy.pp

AppArmor

检查已加载的配置文件：

sudo aa-status

若需配置文件管理工具，请安装实用程序包：

sudo apt install apparmor-utils

在应用程序运行时交互式生成配置文件：

sudo aa-genprof /path/to/binary

通过扫描日志中的违规记录来优化配置文件：

sudo aa-logprof

在不同模式之间切换配置文件：

sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx
sudo aa-complain /etc/apparmor.d/usr.sbin.nginx

该选哪个？

对大多数管理员而言，最实用的答案是：使用发行版自带的方案。RHEL、CentOS、Fedora 和 Rocky Linux 默认搭载 SELinux；Ubuntu、Debian 和 SUSE 则默认搭载 AppArmor。这两种框架在其原生平台上均拥有成熟的工具和策略。在任何发行版上切换至非默认选项都会增加工作量，并削弱社区支持。

除此之外，请根据您的需求做出选择：

• 若需符合 PCI DSS、HIPAA 或 DISA-STIG 合规要求，请选择 SELinux。若在 Kubernetes 或 OpenShift 上运行多租户容器工作负载，请选择 SELinux。若在共享主机上需要容器间隔离，请选择 SELinux。若您的环境处理机密或分级敏感数据，请选择 SELinux。
• 若您运行 Ubuntu 或 Debian 且希望获得 MAC 保护而无需复杂的学习曲线，请选择 AppArmor。若您的环境是运行标准 Web 服务的单服务器或小型集群。若快速部署比细粒度的标签级控制更为重要。

这两种框架均仅带来极小的运行时开销。SELinux 会在其访问向量缓存（AVC）中缓存访问决策。AppArmor 的策略加载可能会在启动时造成轻微延迟，但在运行时影响微乎其微。对于大多数托管工作负载而言，这两者都不会成为性能瓶颈。

若您需要一个可靠的主机基础环境，并拥有完全的 root 权限来配置任一框架，FDC 的专用服务器或 VPS 可为您提供充分的控制权，让您根据环境需求灵活配置 SELinux 或 AppArmor。