SELinux标签不一致不会直接导致崩溃，但会因访问拒绝引发应用异常退出或初始化失败；需先用getenforce确认Enforcing模式，再通过ausearch查AVC拒绝、ps -Z与ls -Z比对进程域和资源类型，最后用semanage fcontext+restorecon修复标签错配。

SELinux 标签不一致本身不会直接导致应用“崩溃”（如 segmentation fault），但会引发关键资源访问被拒绝，进而触发应用异常退出、反复重试、初始化失败或进入不可恢复状态——表现为看似崩溃的行为。排查重点不是找“段错误”，而是定位**被拒绝的访问动作**及其背后**进程域类型与文件/端口/内存对象类型之间的上下文错配**。

确认 SELinux 是否正在生效并拦截

先排除误判：运行 getenforce，输出必须是 Enforcing；若为 Permissive 或 Disabled，则标签问题不会造成实际拦截。

临时验证是否根因：
– 执行 setenforce 0（切宽容模式）
– 立即重启应用（如 systemctl restart nginx 或重新启动 Java 进程）
– 若此时能正常启动且无报错，基本锁定 SELinux 标签不一致是诱因
– 验证后务必执行 setenforce 1 恢复强制模式，避免审计日志失效

查 AVC 拒绝日志，定位具体被拦操作

所有拒绝记录都写入审计日志，不在 /var/log/messages 或 journalctl 默认输出里：

• 查最近拒绝：ausearch -m avc -ts recent
• 按进程名过滤（如 java、nginx、mysqld）：ausearch -m avc -c nginx
• 聚焦内存/共享资源类拒绝：ausearch -m avc -ts recent | grep -i -E "(shm|hugetlb|mmap|anon|tmpfs)"
• 用 audit2why 解读每条：ausearch -m avc -c nginx | audit2why —— 它会指出缺哪条 allow 规则，并建议是 restorecon 还是 setsebool

比对进程域与目标资源的上下文标签

真正关键的是两段标签是否匹配：

Linux Security Scanner

Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...

下载

• 查进程真实域类型：ps -Z -C nginx（看第二字段，如 system_u:system_r:httpd_t:s0 中的 httpd_t）
• 查目标路径类型：ls -Zd /data/app/config（目录自身）或 ls -Z /data/app/config.json（文件）—— 关注第三段，如 default_t、etc_t、tmpfs_t
• 典型错配场景：
  – 应用配置放在 /data/app/conf，但标签是 default_t，而 httpd_t 不被允许读它
  – 共享内存挂载点 /dev/shm 标签是 tmpfs_t，但进程需要 shm_t 权限
  – 大页目录 /hugepages 标签为 default_t，而服务进程域未被授权访问 hugetlbfs_t

修复三类高频标签错配

不靠 chcon 临时改（考试和生产都不推荐），用永久方案：

• 文件/目录标签修复：
  – 添加永久规则：semanage fcontext -a -t httpd_sys_rw_content_t "/data/app/conf(/.*)?"
  – 应用变更：restorecon -Rv /data/app/conf
• 设备或挂载点标签修复（如 /dev/shm、/hugepages）：
  – 查当前策略允许哪些路径带 shm_t：semanage fcontext -l | grep shm_t
  – 若没有，添加：semanage fcontext -a -t shm_t "/dev/shm(/.*)?"
  – 再执行：restorecon -Rv /dev/shm
• 布尔值启用（非标签本身，但常伴随错配出现）：
  – 如应用需网络连接：setsebool -P httpd_can_network_connect on
  – 如需读取用户家目录：setsebool -P httpd_read_user_content on