![SELinux 在启动时重新标记卡住](https://linux22.com/image/732022/SELinux%20%E5%9C%A8%E5%90%AF%E5%8A%A8%E6%97%B6%E9%87%8D%E6%96%B0%E6%A0%87%E8%AE%B0%E5%8D%A1%E4%BD%8F.png)
我在服务器上恢复 SELinux 时遇到了问题,希望得到一些帮助。
语境
在我们的服务器上,我最近将 SELinux 从 更改enforcing
为permissive
,但由于它没有解决我们的一个奇怪问题(意外的权限被拒绝),我甚至将其设置为disabled
... 无论如何,SELinux 不是问题所在。我们弄清楚了,现在它已经解决了 ... 但 SELinux 现已被禁用!
现在我想恢复它。所以我只是将它再次更改为,并希望系统在下次启动时enforcing
自动检测到它需要重新标记(因此不需要),touch /.autorelabel
过去有效的(tm)。遗憾的是它在启动时卡住了,10 分钟后我们又回到禁用状态以恢复服务。文档指出这可能需要很长时间,所以我安排在周末重启。但周末过后它仍然卡在启动状态。
奇怪的是,服务器的硬盘没有显示任何磁盘活动。
当我在虚拟机上执行上述操作时,它会启动到同一点,然后打印一条消息,提示需要执行 SELinux 重新标记并执行该操作。在服务器上,我们看不到该消息。
评论
服务器有一些 CIFS 安装,这是 SELinux 尝试重新标记 CIFS 文件系统的原因吗?这可以解释较长的时间和没有磁盘活动,但不能解释控制台上没有消息的原因。
技术信息
- CentOS 7.6 (1810) x86_64
- 裸机,戴尔服务器,6 个 HDD RAID6(硬件)
- 没有日志写入磁盘,最后启动的单元是
Update UTMP about System Boot/Shutdown.
注意:RHEL 知识库文章建议首先从禁用状态转为通过宽容状态强制执行。每次重新启动时,通过触摸 强制重新标记/.autorelabel
。这将是我周末的下一次尝试。但任何有关发生的事情的见解都欢迎。
更新 01
我现在已经做了进一步的测试。以下所有启动模式均失败:
- 启动
selinux=1, enforcing=0, autorelabel=0
- 启动
selinux=1, enforcing=0, autorelabel=1
- 启动
selinux=1, enforcing=1, autorelabel=0
- 启动
selinux=1, enforcing=1, autorelabel=1
只有使用 启动才selinux=0
有效。我所说的失败,是指启动时控制台上没有错误消息,也没有关于 SELinux 重新标记的消息,系统挂起数小时,看不到磁盘活动。
我现在已经注释掉了cifs
我的所有卷/etc/fstab
,并在宽容模式下重新启动,并启用了自动重新标记。启动大约需要 20 分钟,但我可以看到它在做一些事情(控制台上打印出已开始重新标记,显示 FS(如 sysfs)是只读的并且被忽略,磁盘活动可见,等等)。因此,SELinux 现在已在宽容模式下启用。我现在将在本周末尝试强制模式。
显然,那些 CIFS 挂载似乎是问题所在,但我不明白为什么。在我看来,CIFS 挂载会被重新标记忽略,就像 sysfs 一样。我在这里误解了什么吗?
答案1
有什么特定的原因要使用吗/.autorelabel
?我的理解是它会触发restorecon
。
要弄清楚为什么会挂起,我建议切换到宽容模式,并在没有/.autorelabel
文件的情况下启动机器。当系统启动并运行时,尝试restorecon -rFv /
。最终不要从开始/
,而是从例如/var
或整个系统的一小部分开始。
restorecon 的标志-v
显示了文件系统上正在进行的所有修改。它应该能让你很好地了解在启动过程中它会在哪里“挂起” /.autorelabel
。我预计文件系统中会有一些区域存储大量小文件。或者最终是网络安装的存储。
一旦完成切换,enforcing
就不需要再/.autorelabel
运行了。
[编辑]
我刚刚在 Fedora 29 机器上验证了上述关于/.autorelabel
和的陈述。启动,这是一个 bash 脚本。该脚本使用参数运行。 是另一个实际运行 的 bash 脚本。restorecon
/lib/systemd/system/selinux-autorelabel.service
/usr/libexec/selinux/selinux-autorelabel
/sbin/fixfiles
restore
/sbin/fixfiles
restorecon