SELinux策略冲突本质是策略与服务行为不匹配，解决关键在于让策略理解服务：先查avc: denied日志确认拦截，再调上下文或布尔值，极少需写新策略；必须经permissive模式调试后再切enforcing。
SELinux 策略冲突不是“配置错了”，而是策略与实际服务行为不匹配。解决的关键不是绕过它，而是让策略理解你的服务——先看日志、再调上下文或布尔值，极少需要写新策略。
确认是否真是 SELinux 在拦截
别凭感觉判断。只要系统报 Permission denied，且服务在正常权限下应能运行，就立即查 SELinux 拒绝记录：
- 运行 ausearch -m avc -ts recent，快速抓取最近的拒绝事件
- 或直接搜日志：grep "avc: denied" /var/log/audit/audit.log
看到输出即确认是 SELinux 拦截；若无结果，问题大概率出在传统文件权限、用户组或 systemd 限制上。
看懂拒绝日志里的关键字段
一条典型日志如：avc: denied { read } for pid=1234 comm="httpd" name="config.php" scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file
重点关注四个部分：
-
scontext：进程的安全上下文（这里是
httpd_t，说明是 Apache 进程） -
tcontext：目标资源的上下文（这里是
user_home_t，普通用户家目录类型） -
tclass：资源类型（
file、port、tcp_socket等） -
操作（
{ read }、{ connect }等）：被拒绝的具体动作
例如 httpd_t → user_home_t 的 read 被拒，说明 Apache 尝试读家目录下的文件——这本身就不合规，应把文件移到 Web 可访问路径并设对类型。
优先用上下文和布尔值修复，而非写策略
95% 的冲突靠调整已有机制就能解决，无需 audit2allow：
-
文件/目录访问失败：先 ls -Z /path 看类型。若为
default_t或user_home_t，而服务需读写，就该设成对应类型，如：
– 临时： chcon -R -t httpd_sys_content_t /srv/myapp
– 永久： semanage fcontext -a -t httpd_sys_content_t "/srv/myapp(/.*)?" && restorecon -Rv /srv/myapp -
网络连不上（DB、API、外部服务）：查布尔值，例如：
getsebool -a | grep httpd_can_network
若httpd_can_network_connect_db是off，运行：
setsebool -P httpd_can_network_connect_db on - 端口绑定失败（如监听 8080、3000）：用 semanage port -a -t http_port_t -p tcp 3000 把端口加入允许列表
切忌直接开 enforcing，必须走 permissive 调试流程
新部署服务或修改策略后，标准流程是：
- 确保 /etc/selinux/config 中
SELINUX=permissive - 重启服务，复现操作，用 ausearch 收集所有拒绝项
- 按上述方法逐条修复上下文和布尔值
- 确认服务完全正常后，再改回
SELINUX=enforcing并重启验证
跳过 permissive 阶段直接启用 enforcing，等于闭眼开车——服务极大概率起不来，排查更困难。
