SELinux真正禁用需同时满足：getenforce输出Disabled、sestatus显示SELinux status为disabled且Loaded policy name为空、/sys/fs/selinux路径不存在；仅改配置不重启或存在selinux=1内核参数均无效。
不能只改配置文件就认为“彻底关闭”了——SELinux 的 disabled 状态必须满足两个条件：配置生效 + 内核未加载策略。很多用户改完 /etc/selinux/config 就重启，但 sestatus 仍显示 enabled，根本原因是没确认实际运行态。
怎么确认 SELinux 当前是否真被禁用
别信配置文件，看内核实际状态：
-
getenforce输出Disabled才算成功；输出Permissive或Enforcing都不算 -
sestatus的SELinux status字段必须是disabled，且Loaded policy name为空（不是targeted） - 如果
sestatus报错Permission denied或提示No such file or directory（指/sys/fs/selinux），才是真的 disabled
永久关闭 SELinux 的唯一可靠操作路径
改错配置项、选错文件路径、漏重启，都会导致失败：
- 只修改
/etc/selinux/config，不要碰/etc/sysconfig/selinux（后者在 CentOS 7 中只是符号链接，改它可能无效） - 把
SELINUX=enforcing改成SELINUX=disabled——注意不是permissive，后者仍加载策略、占内存、写日志 - 确保该行未被注释（即开头不能有
#）；SELINUXTYPE行可保留，不影响 disabled 效果 - 必须执行
reboot（或shutdown -r now），init 6在某些 systemd 环境下不触发 SELinux 卸载流程
为什么 setenforce 0 不算“彻底关闭”
这是最常被误解的一点：setenforce 0 只是切到 Permissive 模式，和 disabled 有本质区别：
-
setenforce 0不卸载策略，/sys/fs/selinux依然存在，sestatus显示enabled - AVC 日志仍在写入
/var/log/audit/audit.log，占用磁盘和 I/O - 内核仍维护安全上下文，对容器、NFS、Docker volume 挂载等场景仍有隐性开销
- 该命令重启即失效，无法替代配置+重启流程
改完配置重启后仍没禁用？重点检查这三处
常见“看似改了却没用”的真实原因：
- 编辑的是
/etc/sysconfig/selinux而非/etc/selinux/config——CentOS 7 默认后者才是主配置，前者可能被忽略 - 配置文件里有多处
SELINUX=，只改了注释行（如#SELINUX=enforcing），没改实际生效的那行 - 系统用了 GRUB 内核参数强制启用，检查
cat /proc/cmdline | grep selinux，若含selinux=1或security=selinux，需同步清理 GRUB 配置
真正“彻底关闭”的标志只有一个：重启后 ls /sys/fs/selinux 报错 No such file or directory，且 sestatus 明确说 disabled。其他任何中间状态，都还留着策略加载的痕迹。
