У меня проблема с восстановлением SELinux на сервере, и я хотел бы получить некоторое представление.
На нашем сервере я недавно изменил SELinux с enforcing к permissive, и поскольку это не решило нашу проблему, которая была странной (непредвиденные разрешения запрещены), я даже установил для нее disabled... Во всяком случае, проблема не в SELinux. Мы разобрались, и теперь это решено ... но теперь SELinux отключен!
Теперь хочу его восстановить. Я просто изменил его на enforcing снова, и я ожидал, что система автоматически обнаружит, что ей нужно изменить метку (так что нет необходимости touch /.autorelabel) при следующей загрузке, что работало в прошлом (тм). К сожалению, он застрял во время загрузки, и через 10 минут мы снова отключились, чтобы восстановить службы. В документации указано, что это может занять много времени, поэтому я запланировал перезагрузку на выходные. Ну и после выходных он все еще застрял в багажнике.
Как ни странно, жесткие диски сервера не показывают никакой дисковой активности.
Когда я делаю это на виртуальной машине, она загружается в ту же точку, а затем выводит сообщение о том, что необходимо выполнить перемаркировку SELinux, и делает это. На сервере мы не видим этого сообщения.
На сервере есть несколько монтировок CIFS, может ли это быть причиной того, что SELinux пытается изменить метку файловых систем CIFS? Это могло бы объяснить более продолжительное время и отсутствие активности на диске, но не объясняет отсутствие сообщений на консоли.
Update UTMP about System Boot/Shutdown.Примечание: есть Статья базы знаний RHEL который рекомендует сначала перейти от отключенного к принудительному с помощью разрешающего. И при каждой перезагрузке принудительно перемаркировать, касаясь /.autorelabel. Это будет моя следующая попытка на выходных. Но любое понимание того, что происходит, приветствуется.
Я провел дальнейшее тестирование. Не удалось выполнить все следующие режимы загрузки:
selinux=1, enforcing=0, autorelabel=0selinux=1, enforcing=0, autorelabel=1selinux=1, enforcing=1, autorelabel=0selinux=1, enforcing=1, autorelabel=1Только загрузка с selinux=0 работает. Когда я имею в виду сбой, это означает, что на консоли нет сообщений об ошибках при загрузке или сообщения о перемаркировке SELinux, система зависает на много часов, активность диска не видна.
Я закомментировал все cifs тома из моих /etc/fstab и перезагрузился в разрешении с автопеременной. Загрузка заняла около 20 минут, но я мог видеть, что он что-то делает (на консоли было напечатано, что была начата перемаркировка, показано, что FS, такие как sysfs, доступны только для чтения и игнорируются, активность диска была видна и т. Д.). Итак, SELinux теперь включен в разрешающем режиме. Сейчас я попробую применить принудительный режим в эти выходные.
Очевидно, проблема была в креплениях CIFS, но я не понимаю, почему. Насколько я понимаю, монтирования CIFS будут игнорироваться при перемаркировке, как и sysfs. Я что-то неправильно понял?
Есть ли конкретная причина использовать /.autorelabel? Насколько я понимаю, это вызывает restorecon.
Чтобы понять, почему это зависает, я бы предложил переключиться в разрешающий режим и загрузить машину без /.autorelabel файл. Когда система запущена и работает, попробуйте restorecon -rFv /. В конце концов, не начинайте с / но, например, /var или меньшая часть всей системы.
В -v Флаг restorecon показывает вам все текущие модификации файловой системы. Это должно дать вам хорошее представление о том, где он "зависает" при загрузке с /.autorelabel. Я ожидал, что в файловой системе есть место, где хранится множество крошечных файлов. Или, в конечном итоге, сетевое хранилище.
Как только это будет сделано, переключитесь на enforcing не должен требовать другого /.autorelabel запустить.
[редактировать]
Я только что проверил приведенное выше утверждение относительно /.autorelabel и restorecon на машине Fedora 29. /lib/systemd/system/selinux-autorelabel.service начинается /usr/libexec/selinux/selinux-autorelabel который является сценарием bash. Этот сценарий запускается /sbin/fixfiles с restore параметр. /sbin/fixfiles это еще один сценарий bash, который фактически запускает restorecon.