Portal:SELinux/Troubleshooting
这是 SELinux 问题吗？
如果某些功能未按预期工作，例如由于权限被拒绝，SELinux 可能是罪魁祸首。有一些方法可以确定问题是否与 SELinux 有关。
检查审计日志
首先，您可以检查审计日志中是否有 AVC 拒绝条目。如果在日志中看到 AVC 拒绝，这强烈表明问题是由 SELinux 引起的
列出自启动以来的 SELinux 相关审计事件
# ausearch -ts boot -m avc
除了“boot”之外，其他有用的选项是“today”或“recent”。
审计日志中 AVC 拒绝的示例
# ausearch -ts recent -m avc -c sshd
----
time->Tue May 18 14:47:47 2021
type=AVC msg=audit(1621342067.432:82): avc: denied { read } for pid=839 comm="sshd" name="example.com.3" dev="vda2" ino=199155 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_yp_t:s0 tclass=file permissive=1
----
time->Tue May 18 14:47:47 2021
type=AVC msg=audit(1621342067.432:83): avc: denied { open } for pid=839 comm="sshd" path="/var/yp/binding/example.com.3" dev="vda2" ino=199155 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_yp_t:s0 tclass=file permissive=1
[...]
如果在审计日志中看到 AVC 拒绝，请转到 Portal:SELinux/Troubleshooting#Investigating_Denials 部分，以获取有关调查问题的指导。
如果没有 AVC 拒绝，是否仍然可能是 SELinux？
如果没有任何显示，但您想完全排除 SELinux 作为问题，请尝试将 SELinux 临时设置为 permissive 并检查问题是否仍然存在
setenforce 0
如果 SELinux 设置为 permissive 时问题消失，那么 SELinux 就是罪魁祸首。
要将 SELinux 重新设置为 enforcing，请运行
setenforce 1
如果出现没有 AVC 拒绝并且禁用 SELinux 可以解决问题的情况，请打开一个 bug。为了方便我们，请将 SELinux 重新设置为 enforcing 并重建策略，而不使用所谓的“dontaudit”规则
semodule -DB
然后，重新运行您失败的程序。这应该会在审计日志中提供一些 AVC，请将它们包含在您的 bugreport 中。然后，您可以将策略重建回正常状态：
semodule -B
调查拒绝
一旦您确定存在 SELinux 问题，您可以使用本节中的指示进行调查。如果您无法弄清楚，或者问题不是特定于您的系统，请打开一个 bug。
排除由于标签不一致导致的问题
移动文件
SELinux 类型在创建文件时应用。您可以使用 `ls -lZ` 查看这些类型。当文件被移动时，其类型保持不变。一个常见的例子是，如果您使用 scp 将文件复制到服务器上的主目录，它将被标记为 user_home_t。如果您想将该文件移动到 `/var/www/html` 以供 Web 服务器提供服务，该文件将*不会*自动将其类型更改为 httpd_file_t。
这是一个特性，旨在防止意外泄露不应泄露的信息。
为了避免这种情况，您可以使用“mv -Z src dst”在移动时更新文件的类型标签为目标位置的默认标签。或者，在移动后，您可以使用 `restorecon -v dst` 将类型重置为目标位置的默认值。
重新标记系统
如果您在系统上看到很多 SELinux 拒绝，标签可能会处于不一致的状态。为了尝试修复它，您可以重新标记系统。这可以手动使用
touch /.autorelabel reboot
或者，您可以触发重新标记（这将重新启动您的系统）：
systemctl start selinux-autorelabel
使用 audit2why 深入挖掘
SELinux 可能会拒绝访问的原因有很多，这些原因并非由于系统的不一致性。在确保问题不是由不一致性引起的之后，最容易获得提示的方法是使用 audit2why 工具
来自 policycoreutils-python-utils 包的 audit2why 可以将 ausearch 提供的格式的审计日志输出进行管道传输，从而可能给出一些解释。例如，该工具可能会建议启用一个布尔值
ausearch -ts recent -m avc | audit2why
Was caused by: The boolean nis_enabled was set incorrectly. Description: Allow nis to enabled Allow access by executing: # setsebool -P nis_enabled 1
如果您理解建议和潜在的风险，您可以启用该布尔值。
设置 SELinux 布尔值
SELinux 布尔值是作为管理员调整 SELinux 行为的预期方式（请参阅“man 8 booleans”）。要获取布尔值的描述，您可以运行 semanage（来自 policycoreutils-python-utils 包），要查看布尔值所做的更改，您可以运行 sesearch（来自 setools-console）
semanage boolean -l | grep nis_enabled
sesearch -A -b nis_enabled
要设置布尔值，您可以使用
setsebool -P nis_enabled 1
设置布尔值后，上面的示例问题应该得到解决。
audit2allow
audit2why 给出的另一个建议可能如下所示
Was caused by:
Missing type enforcement (TE) allow rule.
You can use audit2allow to generate a loadable module to allow this access.
这建议使用 audit2allow（来自 policycoreutils-python-utils 包）生成新规则。
audit2allow 工具使用审计消息生成可以加载到 SELinux 中的规则，在转换为正确的格式之后。
例如，在文件 `my_avc` 中有这个 AVC
type=AVC msg=audit(1621342040.556:15): avc: denied { watch } for pid=1 comm="systemd" path="/var/cache/cups" dev="vda2" ino=22stem_r:init_t:s0 tcontext=system_u:object_r:cupsd_rw_etc_t:s0 tclass=dir permissive=1
audit2allow 会建议这个规则
cat my_avc | audit2allow
#============= init_t ============== allow init_t cupsd_rw_etc_t:dir watch;
临时问题
记录会随着时间推移而消失并可能需要临时/一次性修复的问题。
将 libselinux 更新到版本 3.8
用户空间工具更新到版本 3.8 的一部分是文件上下文的二进制文件格式的更改，这可能导致 libselinux 出现以下错误消息
/etc/selinux/targeted/contexts/files/file_contexts.bin: Old compiled fcontext format, skipping /etc/selinux/targeted/contexts/files/file_contexts.homedirs.bin: Old compiled fcontext format, skipping
可以通过运行以下命令修复临时错误：
semodule -B
下次更新 selinux-policy 时，问题将自动修复。