Почему приложения, при SELinux в режиме Permissive, порой работают неправильно?
Это архивная статья
В новогодней статье Dan Walsh
отвечает на интересный вопрос - почему приложения, когда SELinux
переведен в режим Permissive, порой работают
неправильно?
Как известно, SELinux работает в трех режимах - Disabled, Permissive,
Enforcing (рекомендованный). Режим Permissive должен быть идентичен
Enforcing за тем исключением, что все запрещенные действия
разрешаются. Это позволяет отладить политики SELinux для непростых
случаев, чтоб потом переключиться в Enforcing уже с правильными
параметрами. Приложение, когда SELinux включен в режиме Permissive,
должно работать как будто SELinux выключен. К сожалению, это порой не
так, и это очень странно.
Dan разъясняет. Дело в том, что модуль ядра работает хорошо, но есть
еще проверки SELinux в userspace. Dan выделяет следующие сценарии:
- Может ли приложение соединиться с указанным D-Bus демоном?
- Позволено ли приложению запускать один из демонов systemd?
- Может ли процесс, запущенный от суперпользователя, менять пароли?
- Разрешать ли sshd логиниться dwalsh как unconfined_t?
Эти проверки происходят в userspace, и ядерный модуль их не увидит. Их
можно определить по типу сообщения "USER_AVC" в логах. И вот если эти
тесты написаны неправильно, то можно увидеть запреты, даже при
включенном в Permissive режиме SELinux. Такие проверки включены в
самые разные части системы - D-Bus, systemd, X Server, sshd, passwd,
и, к сожалению, в ряде случаев в upstream проектов, люди не хотят
включать дополнительную проверку на Permissive (или еще не
реализовали). Если вы столкнулись с такой проблемой, то открывайте
заявку в Bugzilla.redhat.com, и Dan вам поможет.
В логах эта ситуация видна очень хорошо. Если вы переключили SELinux в
Permissive режиме, и видите флаг success=yes в записи типа USER_AVC
или AVC, то это нормально - сработало правило SELinux, но приложение
получило доступ к запрашиваемому ресурсу. А вот если вы видите флаг
success=no, то самое время сообщить в багзиллу.