使用 SELinux 加固 Linux：完整实用指南

信息技术数字 » 资源 » 使用 SELinux 加固 Linux：完整实用指南

在为生产环境搭建 Linux 服务器时，其默认配置通常相当开放。它的设计目标是开箱即用，而非固若金汤。而 SELinux 正是在此发挥关键的加固作用：它增加了一层控制机制，即使在常规防御措施（文件权限、防火墙、更新）失效的情况下也能继续发挥作用。

SELinux 乍看之下可能令人望而生畏，但一旦掌握了它的基本原理，它就会成为一个极其强大的工具，可以用来遏制漏洞利用、减少损失，并满足CIS、PCI DSS 或其他高危安全标准等安全基准。该系统并非依赖应用程序的正常行为，而是强制每个进程在非常具体的边界内运行。

什么是 SELinux？它为何对 Linux 系统加固至关重要？

安全增强型 Linux (SELinux) 是一种基于强制访问控制(MAC) 的 Linux 内核安全扩展。与经典的 Unix 自主访问控制 (DAC) 不同，后者由文件所有者决定谁可以访问文件，而 SELinux 的规则由中央策略规定，即使是 root 用户也无法在不显式修改的情况下覆盖这些策略。

该模型确保访问决策基于安全标签（上下文）和预定义规则，而不仅仅是读写执行（rwx）权限。即使某个服务已被入侵或拥有过多的权限，SELinux 也能阻止其访问敏感文件、触发其他进程或越过其授权边界在网络中移动。

SELinux 并非取代传统的 DAC，而是对其进行补充。首先，它会检查标准的 Unix 权限，只有当 DAC 允许操作时，SELinux 才会介入并验证其策略。如果 DAC 已经阻止了访问，SELinux 既不会干预也不会记录任何日志，这有助于减少日志噪音并保持性能。

这种分层方法在Red Hat Enterprise Linux、Fedora、SUSE Linux Enterprise 或 openSUSE Leap等企业环境中尤为明显，在这些环境中，SELinux 与系统的其余安全机制以及容器和虚拟机等现代技术集成在一起。

关键概念：SELinux策略、上下文和域

SELinux 的基础是安全策略，它描述了谁可以对什么目标执行什么操作以及如何执行。在这个体系中，进程被视为主体，系统资源（文件、目录、套接字、端口、设备等）被视为客体。

SELinux 不将用户视为“root”或“www-data”之类的名称，而是与这些名称一起使用。 域和类型例如，Apache Web 服务器进程在域中运行。 httpd_t而提供给客户端的文件具有如下类型： httpd_sys_content_t该策略定义了哪些域可以访问哪些类型的对象（文件、目录、套接字、端口……）以及哪些特定权限（读取、写入、执行、获取属性、追加等）。

每个对象都有一个关联的SELinux 上下文，其标签格式如下：

usuario:rol:tipo:nivel

例如，一个文件可以被标记为 system_u:object_r:httpd_sys_content_t:s0哪里 日常管理中最重要的字段通常是类型 (httpd_sys_content_t），它决定哪些进程域将被允许访问。

实际上，SELinux 需要处理数千条规则。为了防止规则过于庞大而难以管理，策略被拆分成独立的模块，这些模块可以单独启用、禁用或更新，而无需重新编译庞大的单体代码块。这在 RHEL、SUSE 和 openSUSE 等系统中尤为重要，因为这些系统中每个相关的服务通常都有自己的策略模块。

SELinux 运行模式：强制模式、宽容模式和禁用模式

SELinux 可以以三种不同的模式运行，这些模式决定了其规则在多大程度上实时应用于系统：

在强制模式下，内核会严格执行策略。任何违反规则的操作都会被阻止并记录日志。当策略经过良好调优时，建议在生产环境中使用此模式，因为 SELinux 在此模式下才能真正发挥其保护作用。

在宽容模式下，SELinux 会继续评估策略，但不会阻止任何操作。所有违规行为都会被记录为警告。此模式非常适合测试、部署新应用程序或微调规则，因为它允许您在不中断服务的情况下检测哪些操作会破坏策略的执行。

在禁用模式下，SELinux 完全禁用。不会强制执行任何策略，也不会生成任何与 SELinux 相关的日志。在禁用模式和活动模式（宽容模式或强制模式）之间切换需要重启系统，因为内核必须在启动时初始化 SELinux 支持才能标记文件系统。

在任何发行版中，一个非常明智的做法是先采用宽松的设置，检查并修正标签和策略问题，只有在一切稳定后才切换到强制设置。永久禁用强制设置会移除最强大的保护层之一。

将 SELinux 集成到 RHEL、Fedora、SUSE 和 openSUSE 中

Red Hat Enterprise Linux、Fedora 及其衍生发行版默认启用 SELinux，通常使用有针对性的策略，主要限制 systemd 和某些用户启动的系统服务。

在 RHEL 中，除了预配置的策略之外，还提供了一系列工具，以避免管理员不断地处理底层规则。SELinux 故障排除工具尤为突出，它可以分析拒绝事件并建议具体的更改（例如激活布尔值、更正上下文或生成额外的模块）。

此外，SELinux 还扩展到容器（例如，使用 Podman）和虚拟化环境。通过适当的标签，即使运行时或虚拟机管理程序中存在漏洞，每个容器或虚拟机也能在内核级别与其他容器或虚拟机隔离。

在 SUSE 生态系统中，SUSE Linux Enterprise Server 的内核和工具中包含了 SELinux 框架，但并未提供全面的官方策略。建议的做法是构建一个针对您环境的自定义策略，或者如果您需要一个支持完整 SELinux 的极简主机来运行容器或虚拟化环境，可以使用像 slemicro 这样的解决方案。

在 openSUSE Leap 中，通常会依赖security:/SELinux_legacy等存储库中提供的策略进行测试，因为对于关键环境而言，理想的策略仍然是经过审查并专门针对部署进行调整的策略。

SELinux策略模型：目标策略、MLS策略和最小策略

SELinux 可以与不同的策略模型配合使用，这些策略模型决定了控制的范围和深度。最常见的三种策略模型是：

这种定向策略专为通用环境设计。它侧重于限制特定服务（尤其是网络守护进程），而将其他进程置于更宽松的域中，甚至完全不加限制。由于它在安全性和兼容性之间取得了良好的平衡，因此是大多数发行版的默认选项。

La 多级安全 (MLS) 策略 将敏感度级别字段添加到上下文中（s0, s1, s2（类别等）并允许 将信息和过程分类到不同的层级它是为有非常严格要求的组织（国防、情报、机密环境）设计的，在这些组织中，谁可以查看或修改哪个级别的数据至关重要。

最低策略是一种简化版策略，规则和控制措施较少。它适用于安全要求有限或希望最大限度减少兼容性影响的系统，但会牺牲 SELinux 的部分限制功能。

在实际部署中，通常最好使用有针对性的模块化策略，逐个模块地调整受保护的内容和方式，而不是尝试管理一个单一的、庞大的整体文件，因为后者更难维护。

上下文管理：查看、更改和恢复 SELinux 标签

SELinux 管理的关键任务之一是确保文件、目录、进程和端口根据策略拥有正确的上下文。上下文分配错误会导致服务停止工作或使资源过度暴露。

要检查文件和目录的 SELinux 上下文，许多标准命令都接受该选项。 -Z。 例如， ls -Z /ruta 你可以看到 每个条目的用户、角色、类型和级别和 ps Zaux 您可以了解当前进程的上下文。

当策略安装完毕且文件系统被标记后（例如使用）， setfiles o fixfiles 与文件 file_contexts每条路线都会收到一个 根据策略，默认类型如果在已标记的目录中创建一个新文件，它将继承目录的类型；但如果从其他位置移动该文件，它将保留其原始标签，这可能会导致不一致。

如果文件或目录树的标签错误，您可以使用以下命令更正它们： restorecon该 将上下文恢复为策略中定义的值。。有这样的选项 -R （递归）和 -v （详细）很容易看出变化所在。对于已经测试了一段时间的系统来说，在从宽松模式切换到强制模式之前，这几乎是一个必不可少的步骤。

要声明新的标签模式，您可以使用 semanage fcontext使用此工具，您可以在保单中填写什么 必须将 SELinux 类型分配给特定路径或正则表达式。然后，您可以使用以下命令将这些更改应用到文件系统： restorecon例如，您可以给一个新的标签。 DocumentRoot 来自 Apache httpd_sys_content_t 这样，Web 服务器就可以在其受限域内读取它。

基本配置：启用 SELinux 并选择模式

SELinux 的全局行为由以下因素控制： /etc/selinux/配置其中模式定义如下（enforcing, permissive o disabled）以及要使用的策略（定向、MLS、最低限度……）。

在像 RHEL 或 Fedora 这样的系统中，目标策略通常会来自 默认启用，并处于强制模式在 SUSE 或 openSUSE 系统中，必须调整 GRUB2 中的内核参数以加载 SELinux 而不是 AppArmor。这涉及添加诸如以下的选项： security=selinux y selinux=1 进入启动行并重新生成 GRUB 配置。

在启动时启用 SELinux 并选择策略后，务必使用以下命令执行初始完整文件系统标记： setfiles 或同等工具。此步骤 这可能需要一些时间，最好在需求低迷时期进行。但这是系统在强制模式下顺利启动的基础。

在从 AppArmor 迁移的环境中，这一点至关重要。 仔细审阅文件。 file_contexts 及其地方变体因为任何严重的系统不一致都可能导致系统无法启动。请事先做好备份并进行操作。 semanage fcontext 政策与系统实际情况相符几乎是强制性的。

SELinux 和 CVE：它们如何帮助缓解漏洞

像红帽这样的厂商会将SELinux纳入其CVE影响评估的考量因素。他们的严重性模型（严重、重要、中等、低）会考虑漏洞是否可以通过配置良好的SELinux限制来缓解或至少加以控制。

在一个严重的远程代码执行漏洞中，类型 Log4Shell（CVE-2021-44228）攻击者可以将代码注入到可从互联网访问的服务中。如果该服务运行在高度受限的 SELinux 域中，则潜在的危害会降低，因为 将无权阅读 /etc/shadow操纵敏感数据库或通过系统进行透视 除了其功能所必需的部分之外。

在诸如CVE-2023-4911（Looney Tunables）之类的权限提升漏洞中，即使攻击者成功获取了 DAC 级别的更高权限，策略仍然可能阻止一些关键操作，例如加载内核模块、写入系统目录或打开某些网络套接字。这导致对新获得的访问权限的使用受到限制。

对于一些中等程度的漏洞（例如 Grafana 中的某些问题），由于需要特殊的配置或难以利用，SELinux 可以起到额外的屏障作用，防止小漏洞演变成严重的安全事件。通常情况下，该策略会直接阻止攻击者入侵系统所需的访问权限。

对于影响较小的漏洞，例如导致用户应用程序（例如 vim 等编辑器）崩溃的错误，SELinux 通常不能决定性地阻止问题本身，但它仍然保持其隔离作用，确保有缺陷的进程不会离开其概念沙箱。

SELinux 实战：Web 服务器隔离的真实案例

想象一下，一台运行 RHEL 或 Fedora 的 Web 服务器，它暴露了多个应用程序，尽管打了补丁保护，但其某个组件仍然存在远程执行漏洞。如果没有 SELinux，攻击者就可以以 Web 服务器用户的身份执行代码，从而安装后门、窃取凭据或入侵其他系统。

在 SELinux 处于强制模式且目标策略经过精心调校的情况下，Apache、Nginx 或类似进程可以在该域下运行。 httpd_t，其中有 权限仅限于标记为诸如此类类型的文件。 httpd_sys_content_t o httpd_sys_rw_content_t并根据适当的上下文对已定义的端口进行受控访问。

这意味着，尽管该漏洞允许执行命令，但被入侵的进程仍无法正常工作。 它无法读取类似这样的文件。 /etc/shadow 也不要触碰数据库目录 标有特定类型（例如） mysqld_db_t），如果网络策略限制，则不得打开与其它内部服务的任意连接。

此次入侵并未造成整个系统被攻破，而是局限于网站域内。虽然仍需调查，但潜在影响要小得多，攻击者的行动难度也大大增加。

布尔值、模块和策略调整工具

除了正确的标签之外，SELinux 的日常工作通常围绕着对基本策略进行细微调整，而无需完全重写它。这时，布尔值和自定义模块就派上了用场。

MGI 布尔值 SELinux 这些是开关，用于改变已编译策略的部分行为。例如，布尔值可以允许或禁止 FTP 服务器写入某些目录（例如，在特定情况下）。 allow_ftpd_anon_write或者说，Web 服务器发起与网络的出站连接。

连接器 getsebool -a o semanage boolean -l 您可以列出这些开关并查看它们的描述。要永久更改它们，您可以使用 setsebool -P nombre_booleano on|off其中选项 -P 参数确保更改保存到磁盘，并在重启后仍然有效。这是根据服务器的具体需求调整“官方”策略的一种非常便捷的方法。

另一方面，使用 策略模块 它允许您在不修改基础策略的情况下扩展或修改规则。您可以使用以下方式查看活动模块： semodule -l要禁用其中一个 semodule -d nombre 或用以下方式重新激活它： semodule -e nombre在 SUSE/openSUSE 中，这对于在稳定部署时微调希望 SELinux 关注的系统部分尤其有用。

当您需要授予非常具体的额外权限时，以下组合适用： audit2allow y semodule 它让生活轻松许多。根据记录来看…… /var/log/audit/audit.log, audit2allow 会显示哪个规则被阻止，并生成一个模块。 安装后，它就能实现之前被禁止的功能。

使用 SELinux 进行日志记录、审计和故障排除

每次 SELinux 阻止策略未授权的操作时， AVC 拒绝 （访问向量缓存拒绝）通常记录在 /var/log/audit/audit.log前提是该服务 auditd esté funcionando。

这些条目包含大量信息：已经尝试过做的事情（avc: denied { append }, write, getattr等等），哪个进程提出了请求（pid, comm=），在哪个文件或资源上（name=, dev=, ino=), 最初的过程是怎样的？scontext）以及目的地的背景（tcontext)起初它们看起来像是晦涩难懂的句子，但经过一些练习，它们对于理解正在发生的事情来说却是无比宝贵的财富。

为了避免手动阅读日志而导致崩溃，可以使用诸如此类的工具。 ausearch 允许按消息类型进行筛选（例如， -m AVC）或通过临时窗口（-ts recent而且，最重要的是， audit2allow 以及诸如 sealert 帮忙 将这些事件翻译成接近人类语言 并显示建议。

典型的故障排除工作流程是使用 audit2allow -w -a 要查看最新通知的解释，请点击此处。 audit2allow -a o -i fichero 检查具体规则，最后…… 决定是否值得创建一个模块来解锁该权限 或者，如果情况恰恰相反，该方块处于安全位置，最好不要碰它。

每当生成模块时 audit2allow -M nombre 并已安装 semodule -i值得仔细检查这些设置，因为该工具往往权限设置较为宽松，可能会授予超出实际需要的访问权限。SELinux 为加强访问权限提供了很大的灵活性，但使用不当最终可能会导致策略本身出现漏洞。

Linux 加固策略中的 SELinux

SELinux 并非孤立存在：它被整合到更广泛的强化策略中，该策略包括限制特权用户、防火墙、SSH 强化、反暴力破解机制和配置自动化。

服务器安装后的一个非常常见的做法是：创建一个具有有限 sudo 权限的用户，使其永远不会以 root 用户身份直接工作；激活网络防火墙（例如 ufw 或 iptables/nftables）；安装 Fail2ban 等工具来阻止重复访问尝试；并按照良好实践配置 SSH（非标准端口、禁用 root 访问、密钥认证、尝试次数限制、强大的加密等）。

在此基础上，SELinux 增加了 MAC 层：即使攻击者通过配置错误的 sudo 权限或 SSH 密码获得了用户访问权限，该策略仍然可以限制该用户访问的进程和文件。虽然并非万无一失，但它可以修复许多通常在 MITRE ATT&CK 等矩阵中描述的自动化攻击所利用的漏洞。

随着服务器数量的增长，手动应用所有这些加固措施变得不切实际。这时，自动化和编排工具（例如 Ansible、Puppet、Chef 以及商业自动化加固解决方案等）就派上了用场，它们可以部署一致的 SELinux 策略、调整布尔值、添加路径标签并维护所需状态，而无需在每台机器上花费数小时。

在拥有数百个节点的组织中，这种自动化可以决定是拥有一个相当同质且安全的环境，还是拥有一个配置不一致的丛林，其中一半的服务器上禁用了 SELinux，“以免打扰任何人”。

最终，当 SELinux 得到良好实施时——具有强制模式、一致的上下文、修订的策略、微调的模块和监控的日志——它就成为了一种安全网，可以阻止异常行为，遏制入侵，并有助于证明正在应用强大的访问控制，以满足审计、法规和安全最佳实践的要求。