CentOS SELinux如何与其他安全模块集成

总体原则与协同机制

• 在 CentOS/RHEL 上，SELinux 提供基于标签的强制访问控制（MAC），应与网络层的 firewalld/iptables/nftables 协同工作，形成“网络层拦截 + 主机层细粒度权限”的纵深防御。SELinux 有三种模式：Enforcing/Permissive/Disabled；在 Enforcing/Permissive 间可用 setenforce 1|0 快速切换，永久变更需编辑 /etc/selinux/config 并重启。日常应结合日志（如 /var/log/audit/audit.log）持续审计与调优。

与防火墙的集成

• 职责划分：用 firewalld 控制“谁能进来/出去”（基于接口、源地址、端口/协议），用 SELinux 控制“进程被允许对哪些对象做什么”（基于主体/客体标签与类型强制）。两者互补，不应相互替代。
• 基本实践（firewalld 示例）：
  • 查看与切换区域/规则：firewall-cmd --get-active-zones、–list-all；按业务划分区域（如 public、management），对管理口仅放通 SSH/数据库 等必要来源与端口。
  • 富规则示例：限制 SSH 频率、仅特定网段访问某端口、对拒绝连接进行日志记录，提升可观测性与抗暴力能力。
  • 规则持久化：所有变更需同时写入“永久”配置并 –reload 生效，避免重启后丢失。

与容器和 Kubernetes 的集成

• 容器运行时：在主机启用 SELinux 时，容器进程与卷挂载会继承或受控于主机策略。为需要更强隔离的工作负载设置容器/卷的 SELinux 类型标签（如容器进程域、日志/临时目录类型），必要时通过 semanage fcontext/restorecon 持久化标签；若使用 Kubernetes，可在 PodSecurityContext.seLinuxOptions 指定 type/level，为关键容器设置专属类型与 MCS 级别，实现多租隔离。
• 编排差异：部分轻量发行版或特定组件在 SELinux 强制模式下存在兼容性问题（如 MicroK8s 官方脚本默认提示在边缘节点禁用 SELinux，若必须使用需为组件编写自定义策略模块并重启服务）；而 AppArmor 在容器场景通常更易即插即用，可作为补充加固手段。

与 AppArmor 的共存与取舍

• 共存原则：二者同属 LSM，在 CentOS/RHEL 上通常以 SELinux 为主；若确有需要，可在评估后启用 AppArmor 为特定进程提供路径基的策略兜底。避免在同一工作负载上同时启用两套“强 MAC”而产生策略冲突与排障复杂度。
• 启用与验证（示例）：安装工具包（如 apparmor-utils），为关键服务加载或调整策略文件，使用 aa-status 查看加载状态，结合系统日志观察拒绝事件；对容器/虚拟机场景可按需为守护进程、容器运行时或虚拟化组件配置专用 AppArmor 配置。

故障排查与运维要点

• 快速定位：遇到“权限被拒”时，先确认 SELinux 模式 与策略类型（getenforce、sestatus），再用 ausearch -m AVC -ts recent 检索拒绝日志，配合 audit2why 分析原因；确需放行时，优先用 semanage fcontext/restorecon 修正标签，或用 audit2allow -M 生成自定义模块并 semodule -i .pp（谨慎评估最小权限）。
• 变更与回滚：在 Permissive 模式验证策略变更的影响，再切回 Enforcing；对 firewalld 规则采用“永久配置 + 动态重载”，并保留变更记录以便审计与回滚。