Ubuntu 上 SELinux 漏洞检查与风险排查

开门见山，咱们直奔主题。在 Ubuntu 的世界里，SELinux 并非默认的“守门员”，AppArmor 才是更常见的选手。但如果你出于某些特定需求，已经手动启用了 SELinux，那么接下来的内容就是为你准备的。本文将带你系统地检查它的安全状态，并揪出那些可能被利用的薄弱环节。要知道，SELinux 的风险往往潜藏于几个关键点：运行在宽容（Permissive）或禁用（Disabled）模式、策略过于宽松（比如开启了大量布尔值）、关键文件或进程的上下文标签错误，以及被 dontaudit 规则隐藏而未被发现的拒绝事件。

一、快速检查清单

别被复杂的名字吓到，按部就班来，咱们用一系列命令就能摸清底细。这个清单覆盖了从“是否启用”到“日志是否完备”的所有关键环节。

• 检查运行状态与策略
  • 查看整体状态：执行 sestatus。重点关注输出中的 “SELinux status”、“Current mode” 和 “Loaded policy name”。
  • 快速确认模式：运行 getenforce，它会直接告诉你当前是强制（Enforcing）、宽容（Permissive）还是禁用（Disabled）。
  • 核对配置文件：看看 /etc/selinux/config 文件里的设定，命令是 cat /etc/selinux/config，主要看 SELINUX= 这一行。
• 检查策略开关与行为
  • 列出布尔值：使用 sestatus -b 可以查看所有布尔开关的状态。如果想针对特定服务（比如 httpd）查看，可以用 getsebool -a | grep <服务名>。
• 检查拒绝日志与告警
  • 审计日志：这是金矿。用 ausearch -m a vc -ts recent 查找最近的访问向量缓存（A VC）拒绝消息，或者用 aureport -m a vc 生成一份报告。
  • 系统日志：别忘了去系统日志里翻翻，命令如 grep -i “denied” /var/log/audit/audit.log 或 journalctl | grep A VC。
• 检查文件与进程上下文
  • 文件/目录上下文：ls -Z /path 这个命令能让你看到指定路径下文件和目录的安全上下文标签。
  • 进程上下文：ps -eZ | grep <进程名> 可以查看特定进程运行时的安全上下文。
• 检查审计服务
  • 服务状态：日志能记录的前提是审计服务（auditd）在运行。用 systemctl status auditd 检查状态，如果没启动，记得执行 sudo systemctl start auditd && sudo systemctl enable auditd 来启动并设置开机自启。
• 辅助定位工具
  • 图形化分析：如果问题比较棘手，可以尝试 sealert -a /var/log/audit/audit.log 命令（需要先安装 setroubleshoot 套件），它能提供更友好的分析和建议。

二、判定是否存在可被利用的薄弱点

收集完信息，接下来就是判断环节。哪些信号是高风险的红旗？这里给你划出重点。

• 高风险信号
  • 当前模式显示为 Permissive 或 Disabled。这意味着策略要么没被强制执行，要么完全没起作用，安全防护形同虚设。
  • 配置虽然是 Enforcing，但系统日志里存在大量 A VC denied（访问被拒绝）记录，并且已经影响到正常业务。这种情况往往意味着管理员可能为了“省事”，通过放宽布尔值、设置错误上下文或添加缺失规则等方式“放行”了本应拒绝的操作，从而留下了隐患。
  • 关键目录或二进制文件（如 Web 根目录、系统命令）使用了过于宽泛的上下文（例如 unconfined_t），或者标签完全错误（比如给数据目录打上了 httpd_sys_content_t）。同时，大量使用的 dontaudit 规则可能导致真正的攻击行为被隐藏，无法在日志中留下痕迹。
• 快速验证方法（仅用于排查，验证完务必恢复）
  • 临时切换模式：如果怀疑是 SELinux 策略导致的问题，可以临时执行 sudo setenforce 0 切换到宽容模式（重启后失效）。如果问题随之消失，那基本可以确定是 SELinux 策略配置不当。排查完毕后，务必执行 sudo setenforce 1 切回强制模式。
  • 探查隐藏的拒绝：当怀疑拒绝事件被 dontaudit 规则隐藏时，可以短暂执行 sudo semodule -DB 来临时禁用所有 dontaudit 规则。然后复现问题，并用 ausearch 或 aureport 观察日志，确认是否有新的拒绝记录出现。验证完成后，记得执行 sudo semodule -B 恢复原状。

三、修复与加固建议

发现问题后，如何修复和加固？记住一个核心原则：最小权限和可审计。优先修正上下文和定制规则，放宽布尔值开关是最后的选择。

• 确保强制模式生效：首先，用 sudo setenforce 1 立即切换到强制模式，并检查 /etc/selinux/config 文件，确保 SELINUX=enforcing，以保证重启后依然有效。
• 修正文件/目录上下文（示例）
  • 假设你需要让 Web 服务器访问 /data/www 目录，正确的做法不是关闭 SELinux，而是给它打上正确的标签：
    sudo semanage fcontext -a -t httpd_sys_content_t “/data/www(/.*)?”
    然后应用新的上下文规则：
    sudo restorecon -R -v /data/www
• 按需调整布尔值（遵循最小化原则）
  • 查看某个布尔值的状态：getsebool
    临时开启或关闭：sudo setsebool on|off
    如果需要永久生效，记得加上 -P 参数：sudo setsebool -P on|off
• 基于日志生成最小可用策略模块（示例）
  • 如果日志显示是合法的访问被拒绝，可以基于日志生成自定义策略模块：
    ausearch -c ‘httpd’ –raw | audit2allow -M my-httpd
    这会生成 my-httpd.pp 策略模块文件，然后加载它：
    sudo semodule -i my-httpd.pp
• 保障日志完整
  • 再次确认 auditd 服务正在运行且已设置为开机自启：sudo systemctl enable –now auditd。完整的日志是后续审计和排查的基石。

四、持续监控与告警

对于生产环境，一次性的修复不够，我们需要持续的眼睛。利用 Node Exporter 的 SELinux 收集器，可以将关键指标暴露给 Prometheus，并在 Grafana 中实现统一监控和告警。

• 关键监控指标：
  • node_selinux_enabled：SELinux 是否启用（1为是，0为否）。
  • node_selinux_config_mode：配置文件中的模式（enforcing, permissive, disabled）。
  • node_selinux_current_mode：当前实际运行的模式。
• 建议设置的核心告警规则：
  • 当 node_selinux_enabled == 0 时告警：SELinux 被禁用。
  • 当 node_selinux_current_mode == -1 时告警：系统处于宽容模式。
  • 当 node_selinux_config_mode != node_selinux_current_mode 时告警：配置模式与实际运行模式不一致（例如配置为enforcing但实际是permissive）。

这套方案能帮助你及时发现 SELinux 状态被意外更改或策略执行中断的风险，让安全防护始终在线。