Dan Walsh о том, почему SELinux не защищает Firefox
Опубликовано 12.8.2015 11:05 пользователем Peter Lemenkov
Dan решил объяснить, почему SELinux не смог бы предотвратить недавнюю уязвимость в Firefox. К сожалению, как пишет в своем блоге Dan, проблема гораздо серьезней.
Для начала, Firefox пока вынужден общаться с устаревшей и небезопасной системой X11, и, например, хотя возможность заблокировать извне процесс от получения информации о нажатых клавишах (т.е. от работы кейлоггером) есть, но применив ее Dan обнаружил, что очень много ПО перестало работать. Также любое ПО может снимать скриншоты экрана, или обладать доступом к буферу обмена (в Wayland, спроектированном с учетом современных требований, это будет исправлено).
Еще одна проблема, это доступ к файлам в домашней директории. В ряде случаев бывает, что пользователь, например, переопределяет папки для сохранения загруженных файлов, и поэтому белый список ввести не получится. Ввести не белые, а ченые списки (например, запретить Firefox доступ к ~/.ssh) тоже не сработает, т.к. есть варианты работы с аутентификацией по ssh-ключу.
Проблемой безопасности является и доступ к D-Bus, к камере, к микрофону, к GPS и т.п. - запрещать это на уровне SELinux нельзя. Непросто и написать правила для приложений-хелперов. Например, если Firefox запустит LibreOffice для открытия документа, то в каком пространстве SELinux нужно запустить LO? В пространстве Firefox или в своем?
Самым простым было ограничение возможностей у дополнений Firefox. Конечно, пришлось ввести дополнительные флаги SELinux для полного отключения ограничений для ряда популярных приложений - на случай, если им потребуется дополнительные права. Хотя, конечно, лучше проприетарные плагины вовсе не использовать.
В ближайшем будущем, благодаря Alex Larsson, который разрабатывает новый стандарт распространения и работы с десктопными приложениями, эти проблемы будут решены. Каждое приложение будет работать в своем контейнере, с ограничениями SELinux, и под Wayland. Почти все проблемы, благодаря этой связке, будут решены. Примерно так и работают приложения в Android, благодаря SEAndroid, о котором мы вам рассказывали.
Кстати, если вы почему-то не используете Fedora, то требуйте от мэйнтейнеров вашего дистрибутива включать SELinux - на его использование будет завязано все больше и больше ПО.
Раз уж заговорили о безопасности, то стоит отметить, что в Fedora наши коллеги относятся к ней очень тщательно. Ну, по крайней мере, мы стараемся. Например, много вопросов было от переключавшихся с других дистрибутивов, почему у нас не работает добавление пользователя в группу "docker". В ряде других дистрибутивов после добавления пользователя в эту группу, ему позволяется запускать контейнеры, а у нас ему нужно поднять свои привилегии до суперпользователя с помощью su или sudo. Проблема в том, что если разрешить пользователю запускать произвольные контейнеры, он сумеет получить полный доступ к файловой системе от суперпользователя. Т.е. добавив его в группу docker мы фактически даем ему право выполнять sudo без пароля. И т.к. в Docker журналирование событий крайне убогое (как и много чего еще), то это рассматривается, как дыра в безопасности. Dan Walsh решил завести специальный тикет с объяснением на GitHub, чтобы не повторяться вновь и вновь. Конечно, лучше бы вам вообще не использовать Docker для контейнеров, т.к. systemd и сопутствующее ПО предоставляют гораздо больше возможностей для этого.
Для начала, Firefox пока вынужден общаться с устаревшей и небезопасной системой X11, и, например, хотя возможность заблокировать извне процесс от получения информации о нажатых клавишах (т.е. от работы кейлоггером) есть, но применив ее Dan обнаружил, что очень много ПО перестало работать. Также любое ПО может снимать скриншоты экрана, или обладать доступом к буферу обмена (в Wayland, спроектированном с учетом современных требований, это будет исправлено).
Еще одна проблема, это доступ к файлам в домашней директории. В ряде случаев бывает, что пользователь, например, переопределяет папки для сохранения загруженных файлов, и поэтому белый список ввести не получится. Ввести не белые, а ченые списки (например, запретить Firefox доступ к ~/.ssh) тоже не сработает, т.к. есть варианты работы с аутентификацией по ssh-ключу.
Проблемой безопасности является и доступ к D-Bus, к камере, к микрофону, к GPS и т.п. - запрещать это на уровне SELinux нельзя. Непросто и написать правила для приложений-хелперов. Например, если Firefox запустит LibreOffice для открытия документа, то в каком пространстве SELinux нужно запустить LO? В пространстве Firefox или в своем?
Самым простым было ограничение возможностей у дополнений Firefox. Конечно, пришлось ввести дополнительные флаги SELinux для полного отключения ограничений для ряда популярных приложений - на случай, если им потребуется дополнительные права. Хотя, конечно, лучше проприетарные плагины вовсе не использовать.
В ближайшем будущем, благодаря Alex Larsson, который разрабатывает новый стандарт распространения и работы с десктопными приложениями, эти проблемы будут решены. Каждое приложение будет работать в своем контейнере, с ограничениями SELinux, и под Wayland. Почти все проблемы, благодаря этой связке, будут решены. Примерно так и работают приложения в Android, благодаря SEAndroid, о котором мы вам рассказывали.
Кстати, если вы почему-то не используете Fedora, то требуйте от мэйнтейнеров вашего дистрибутива включать SELinux - на его использование будет завязано все больше и больше ПО.
Раз уж заговорили о безопасности, то стоит отметить, что в Fedora наши коллеги относятся к ней очень тщательно. Ну, по крайней мере, мы стараемся. Например, много вопросов было от переключавшихся с других дистрибутивов, почему у нас не работает добавление пользователя в группу "docker". В ряде других дистрибутивов после добавления пользователя в эту группу, ему позволяется запускать контейнеры, а у нас ему нужно поднять свои привилегии до суперпользователя с помощью su или sudo. Проблема в том, что если разрешить пользователю запускать произвольные контейнеры, он сумеет получить полный доступ к файловой системе от суперпользователя. Т.е. добавив его в группу docker мы фактически даем ему право выполнять sudo без пароля. И т.к. в Docker журналирование событий крайне убогое (как и много чего еще), то это рассматривается, как дыра в безопасности. Dan Walsh решил завести специальный тикет с объяснением на GitHub, чтобы не повторяться вновь и вновь. Конечно, лучше бы вам вообще не использовать Docker для контейнеров, т.к. systemd и сопутствующее ПО предоставляют гораздо больше возможностей для этого.