История изменений
Исправление ivanov17, (текущая версия) :
Я в такие истории не влетал, всегда спасала перемаркировка.
Перед перезагрузкой /.autorelabel создавал?
Если создавал и не работает (я бы перепроверил на всякий случай), то ищи как восстановить контексты файлов без перезагрузки.
Первое, что гуглится, это fixfiles, справка для RHEL5, где он упоминается, и справка по SELinux для RHEL9.
fixfiles в актуальной федоре присутствует, можешь попробовать, но сначала погугли какие-нибудь гайды. Я его никогда сам не запускал, хотя пишут, что при наличии /.autorelabel при загрузке именно он и стартует.
Тут какая история: SELinux прекрасно работает пока всё в порядке. Есть политики безопасности, и каждый файл, который создаётся в системе, всегда создаётся с определённым контекстом SELinux, учитывая правила, которые в этих политиках определены.
Но однажды происходит что-нибудь эдакое, что на защищённой системе по определению происходить не должно. Например, ты монтируешь её корень в директорию, делаешь туда chroot и вносишь какие-то изменения. Изменённые файлы лишаются меток.
Когда ты после этого загружаешься в систему снова, SELinux видит какие-то незнакомые файлы без меток и сообщает, что с этим он работать не будет. А у него основной принцип, что запрещено всё, что не разрешено.
Если от изменённых файлов зависит работа системы, то система предсказуемо не загрузится. Единственный способ исправить это – дать SELinux понять как работать с этими файлами. То есть, провести маркировку.
В RHEL и RHEL-based дистрибутивах SELinux включён по умолчанию. SLES/openSUSE/Ubuntu используют Apparmor, который разрешает всё, что не запрещено. Емнип, встальные никаких модулей безопасности по умолчанию не включают.
Исправление ivanov17, :
Я в такие истории не влетал, всегда спасала перемаркировка.
Перед перезагрузкой /.autorelabel создавал?
Если создавал и не работает (я бы перепроверил на всякий случай), то ищи как восстановить контексты файлов без перезагрузки.
Первое, что гуглится, это fixfiles, справка для RHEL5, где он упоминается, и справка по RHEL9.
fixfiles в актуальной федоре присутствует, можешь попробовать, но сначала погугли какие-нибудь гайды. Я его никогда сам не запускал, хотя пишут, что при наличии /.autorelabel при загрузке именно он и стартует.
Тут какая история: SELinux прекрасно работает пока всё в порядке. Есть политики безопасности, и каждый файл, который создаётся в системе, всегда создаётся с определённым контекстом SELinux, учитывая правила, которые в этих политиках определены.
Но однажды происходит что-нибудь эдакое, что на защищённой системе по определению происходить не должно. Например, ты монтируешь её корень в директорию, делаешь туда chroot и вносишь какие-то изменения. Изменённые файлы лишаются меток.
Когда ты после этого загружаешься в систему снова, SELinux видит какие-то незнакомые файлы без меток и сообщает, что с этим он работать не будет. А у него основной принцип, что запрещено всё, что не разрешено.
Если от изменённых файлов зависит работа системы, то система предсказуемо не загрузится. Единственный способ исправить это – дать SELinux понять как работать с этими файлами. То есть, провести маркировку.
В RHEL и RHEL-based дистрибутивах SELinux включён по умолчанию. SLES/openSUSE/Ubuntu используют Apparmor, который разрешает всё, что не запрещено. Емнип, встальные никаких модулей безопасности по умолчанию не включают.
Исходная версия ivanov17, :
Я в такие истории не влетал, всегда спасала перемаркировка.
Перед перезагрузкой /.autorelabel создавал?
Если создавал и не работает (я бы перепроверил на всякий случай), то ищи как восстановить контексты файлов без перезагрузки.
Первое, что гуглится, это fixfiles и справка для RHEL5.
fixfiles в актуальной федоре присутствует, можешь попробовать, но сначала погугли какие-нибудь гайды. Я его никогда сам не запускал, хотя пишут, что при наличии /.autorelabel при загрузке именно он и стартует.
Тут какая история: SELinux прекрасно работает пока всё в порядке. Есть политики безопасности, и каждый файл, который создаётся в системе, всегда создаётся с определённым контекстом SELinux, учитывая правила, которые в этих политиках определены.
Но однажды происходит что-нибудь эдакое, что на защищённой системе по определению происходить не должно. Например, ты монтируешь её корень в директорию, делаешь туда chroot и вносишь какие-то изменения. Изменённые файлы лишаются меток.
Когда ты после этого загружаешься в систему снова, SELinux видит какие-то незнакомые файлы без меток и сообщает, что с этим он работать не будет. А у него основной принцип, что запрещено всё, что не разрешено.
Если от изменённых файлов зависит работа системы, то система предсказуемо не загрузится. Единственный способ исправить это – дать SELinux понять как работать с этими файлами. То есть, провести маркировку.
В RHEL и RHEL-based дистрибутивах SELinux включён по умолчанию. SLES/openSUSE/Ubuntu используют Apparmor, который разрешает всё, что не запрещено. Емнип, встальные никаких модулей безопасности по умолчанию не включают.