第 5 章 故障排除与 SELinux 相关的问题
如果您计划在之前禁用 SELinux 的系统中启用 SELinux,或者您以非标准配置运行服务,您可能需要排除 SELinux 可能会阻断的问题。请注意,在多数情况下,SELinux 拒绝通常代表存在错误的配置。
5.1. 识别 SELinux 拒绝
只执行此流程中的必要步骤 ; 在大多数情况下,您只需要执行第 1 步。
步骤
当您的情况被 SELinux 阻止时,
/var/log/audit/audit.log
文件是第一个检查有关拒绝的更多信息。要查询审计日志,请使用ausearch
工具。因为 SELinux 决策(如允许或禁止访问)已被缓存,且这个缓存被称为 Access Vector Cache(AVC),所以对消息类型参数使用AVC
和USER_AVC
值,例如:# ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR -ts recent
如果没有匹配项,请检查 audit 守护进程是否正在运行。如果没有,请在启动
auditd
后重复拒绝的场景,然后再次检查审计日志。如果
auditd
正在运行,但ausearch
的输出中没有匹配项,请检查systemd
Journal 提供的消息:# journalctl -t setroubleshoot
如果 SELinux 处于活跃状态,且 Audit 守护进程没有在您的系统中运行,在
dmesg
命令的输出中搜索特定的 SELinux 信息:# dmesg | grep -i -e type=1300 -e type=1400
即使进行了前面的三个检查后,您仍可能找不到任何结果。在这种情况下,因为
dontaudit
规则,可以静默 AVC 拒绝。要临时禁用
dontaudit
规则,请记录所有拒绝:# semodule -DB
在重新运行拒绝的场景并使用前面的步骤查找拒绝信息后,以下命令会在策略中再次启用
dontaudit
规则:# semodule -B
如果您应用了前面所有四个步骤,这个问题仍然无法识别,请考虑 SELinux 是否真正阻止了您的场景:
切换到 permissive 模式:
# setenforce 0 $ getenforce Permissive
- 重复您的场景。
如果问题仍然存在,则代表 SELinux 以外的系统阻断了您的场景。