В новогодней статье 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, то самое время сообщить в багзиллу.