总体影响
在 CentOS 上禁用 SELinux 会移除内核级的强制访问控制（MAC）防护，进程与用户仅受传统 DAC（文件权限、能力集等）约束，系统的纵深防御能力明显下降。官方建议优先使用 Permissive（宽容）模式而非永久禁用，以便在保留策略加载与日志的同时排查问题。
机制层面的变化
- 策略不再加载与执行：内核不会加载任何 SELinux 策略，所有主体对客体的访问不再被 SELinux 规则约束。
- 无拒绝日志：不会产生 AVC（Access Vector Cache）拒绝日志，失去基于策略的审计与取证线索。
- 状态语义：禁用与“宽容模式”不同，后者仍加载策略并记录违规但不阻断。
- 生效方式：需在 /etc/selinux/config 中将 SELINUX=disabled 并重启；仅用 setenforce 0 只是临时切到宽容模式，重启后恢复配置值。
安全与合规影响
- 攻击面扩大：失去进程沙盒化与最小权限约束，一旦应用被入侵，横向移动与提权更容易。
- 合规风险：部分安全基线或行业规范（如 PCI DSS 等）要求启用强制访问控制机制；禁用 SELinux 可能导致不合规。
- 日志与追溯：没有 AVC 拒绝日志，安全事件调查难度上升。
运维与兼容性的实际后果
- 兼容性问题可能减少：某些与 SELinux 策略冲突的应用或服务在禁用后可恢复运行。
- 性能变化：SELinux 检查通常带来轻微开销；禁用后可能略有性能提升，但收益有限且以安全为代价。
- 调试路径改变：原本由策略触发的权限问题将不再出现，排查将更多依赖传统权限、服务配置与网络策略。
- 风险控制建议：若仅为排障，优先使用 Permissive 模式观察日志；确需禁用时，应同步强化其他安全措施（如最小化服务、最小权限、及时打补丁、加强防火墙等）。
更安全的替代做法与验证
- 推荐替代：将 /etc/selinux/config 设为 SELINUX=permissive 并重启，保留策略加载与日志以便定位问题；确认命令为 getenforce/Permissive。
- 临时切换：使用 setenforce 0/1 在 Enforcing/Permissive 间切换（无需重启），用于短时验证。
- 状态核验：使用 sestatus、getenforce 或检查 /sys/fs/selinux/enforce（1=Enforcing，0=Permissive，文件不存在或为其他值通常对应 Disabled）确认当前状态。
