Вчера я добавил диск в виртуальную машину Centos6, создал точку монтирования / home на диске, а затем переместил на нее пользователя (в данном случае jenkins), чтобы освободить место в точке монтирования /.
Казалось, что это работает нормально, и разрешения и метки выглядят правильно, но ранее сегодня я начал замечать проблемы, когда я не мог подключиться по SSH к ящику как пользователь jenkins из любого ящика. SSHing к ящику как root и suing to jenkins работал нормально. Вдобавок к этому, если бы я сделал service sshd stop а потом /usr/sbin/sshd Затем я мог подключиться к коробке напрямую как пользователь jenkins.
После долгой отладки я в конце концов заметил отказы SELinux в /var/log/audit/audit.log вот так:
type=AVC msg=audit(1428584552.564:187): avc: denied { search } for pid=1798 comm="sshd" name="/" dev=sdd1 ino=2 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=dir
type=AVC msg=audit(1428584552.567:188): avc: denied { getattr } for pid=1798 comm="sshd" path="/home" dev=sdd1 ino=2 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=dir
Установка SELinux на permissive позволила мне удаленно подключиться как пользователь jenkins.
Я не слишком хорошо разбираюсь в SELinux, но после прочтения (снова) Руководства Gentoo по SELinux Я прочитал эти ошибки как sshd, пытающийся получить доступ как к /, так и к / home с системным контекстом system_u:system_r:sshd_t:s0. Вместо этого эти конечные точки помечены как system_u:object_r:file_t:s0 который, по крайней мере, обозначен как каталог / home (не слишком уверен, как увидеть метку для /).
На мой взгляд, эти метки подходят для этих каталогов, и я не совсем уверен, почему он пытается искать метку sshd_t так далеко вверх по дереву каталогов.
Запуск ls -laZ для получения важных частей (папка .ssh и authorized_keys) дает мне:
drwx------. jenkins jenkins unconfined_u:object_r:ssh_home_t:s0 .ssh
и
-rw-------. jenkins jenkins unconfined_u:object_r:ssh_home_t:s0 authorized_keys
Это выглядит так же, как и другие поля, которые я проверяю, и они работают нормально.
Что мне нужно сделать, чтобы заставить SELinux сотрудничать, чтобы я мог вернуться к принудительному исполнению?
РЕДАКТИРОВАТЬ: Я пробовал umount / home и использовал restorecon, чтобы попытаться переименовать каталог благодаря Предложение Майкла Хэмптона но это не изменило метку в каталоге и, как упоминалось выше, system_u:object_r:file_t:s0 label для / home выглядит правильно по сравнению с другими окнами, которые работают нормально.
Есть ли способ изменить системный контекст sshd при попытке доступа к этому каталогу?
Вы не смотрите в нужные каталоги.
Ваши отказы AVC касаются конкретно контекста / и /home соответственно, ни в каком файле внутри них.
Это заставляет меня подозревать, что у вас неправильная маркировка не только этих записей каталога.
Вот как я бы вылечился:
/home. Это необходимо, потому что мы хотим восстановить контекст файла в точке монтирования в родительской файловой системе, а также контексты файлов в дочерней файловой системе.Восстановить контексты файлов для /home точка крепления.
restorecon -v /home
Перемонтировать /home.
На всякий случай восстановите контексты файлов для всей системы. Это можно сделать одним из двух способов:
touch /.autorelabel и перезагрузитесь. Система будет переименована во время запуска.restorecon -r -v / и перезагрузитесь, когда закончите. Я обычно использую этот метод, так как он дает вам полный список файловых контекстов, которые были изменены.После изменения метки и перезагрузки вы можете безопасно вернуться к принудительному применению SELinux.