Уязвимости в Росе. Почему binfmt для Wine — небезопасно?

Решил собрать в одном месесте свои мысли о том, какие глобальные уязвимости есть в дистрибутиве ROSA Fresh. Обратите внимание, что речь идет о «десктопной» Росе, потомке Mandriva, а не их «серверных» дистрибутивах на базе CentOS.

Список претензий к безопасности в Росе

1. Обычно очень медленное закрытие уязвимостей (CVE) в пакетах в репозитории. К примеру, в ядре Linux находят уязвимость, в течение суток во всех или почти всех ведущих дистрибутивах (Ubuntu, Debian, Red Hat/CentOS, Fedora, OpenSUSE) пользовательям прилетает обновление с закрытием уязвимости. В Росе же могут вообще долгое время ее не закрывать, а  могут закрыть, но положить новое ядро в тестовый репозиторий, где оно промаринуется около недели. Еще как-то, если я в свое время правильно посчитал, в Росе в репозиториях пролежал MySQL с несколькими серьезными уязвимостями в течение около полугода с момента их оглашения, а потом проблему исправили обновлением до новой мажорной версии MySQL, где он еще и отвалился. В ведущих дистрибутивах патчат текущую версию или обновляют до новой минорной версии, а не мажорной, чтобы не поломать обратную совместимость с существующими системами.
2. В системе отсутствуют средства дополнительной безопасности типа AppArmor или SELinux, которые обеспечивают дополнительную защиту от эксплуатации возможных уязвимостей за счет ограничения полномочий критичных компонентов системы, разрешая им делать только то, что разрешено, а все остальное запрещая, тем самым делая невозможным эксплуатацию уязвимости в ограничиваемых программах, через которую можно было бы получить доступ к системе. В Ubuntu и OpenSUSE по умолчанию включен AppArmor, в RHEL/CentOS и Fedora — SELinux. А просто так взять и собрать AppArmor/SELinux для Росы не получится, т.к. они оба бесполезны без набора предустанволенных настроек, а их нужно адаптировать для конкретно Росы и заниматься этим постоянно.
3. Бинарный мусор с недоверенным содержимым в репозитории и наплевательское отношение к порядку в репозитории. Пример — пакет portwort-install: взят PortWot, то есть уже скормпилированный в постороннем месте, а не на сборочнице, Wine, бинарные и с несвободной лицензией файлы игры World of Tanks для Windows, и это все положено в репозиторий дистрибутива Linux!Более того, PortWot после первого запуска в домашней папке (/home/…) хранит бинарные файлы игры и Wine. В Linux не принято так делать, все программы (исполняемые файлы) должны храниться в корне системы. В любом нормальном дистрибутиве Linux каждый компонент (!!), вся система целиком (!!) собирается из исходных кодов на сборочнице (ферма, сервера, занимающиеся компиляцией), а в репозиторий кладутся скомпилированные бинарные пакеты. Исключение составляют только проприетарные драйверы Nvidia, Broadcom и firmware в пакете linux-firmware. Ставя что-то из репозиториев Ubuntu, которой я пользуюсь, я уверен, что пакет скомпилирован из исходных кодов и наверянка качественно приготовлен (кроме описанных выше исключений). В Росе есть репозиторий non-free для несвободных компонентов типа проприетарных драйверов, название non-free переводится как «несвободный». Есть репозиторий main, куда попадают ключевые компоненты системы, поддерживаемые и тестируемые разработчиками Росы, а есть contrib, где лежат пакеты, собранные сообществом и не тестируемые разработчиками Росы. Все эти репозитории из корокби включены в ROSA Fresh. portwot-install лежит в contrib. Как я могу доверять вообще чему-то в дистрибутиве, где в репозитории лежит непонятно что, не просто исполняемые файлы без исходного кода и под проприетарной лицензией, а еще и даже Wine, скомпилированный не на сборочнице?! Я предлагал это перенести хотя бы в non-free (по-хорошему нужно убрать из репозитория, но жалко), но авторам пофиг, похоже.Telegram, собственно, тоже упаковывается в Contrib из уже скомпилированных бинарников, в которые разработчики Telegram неконтролируемо могут встроить любой функционал. Хотя уже можно собрать его из исходников, как это делается в Debian или в ALT. Раньше Telegram нельзя было скомпилировать в репозиторие,несмотря на открытый код, т.к. требовалась пропатченная версия Qt, но уже больше не требуется.
4. Плохая проработка безопасности при сборке пакетов в репозитории. Пример пока только один: зачем в пакете Wine Staging binfmt?! Он не нужен для работы Wine, но это создает потенциальную дыру в безопасности! В Debian/Ubuntu есть отдельный пакет wine-binfmt, установка которого включает binfmt для Wine, однако он лишь предлагаемая (suggests) зависимость пакета wine, то есть по умолчанию не устанавливается.

Резюме. К сожалению, получается, что Роса Фреш, из известных мне популярных дистрибутивов самый небезопасный.

Что такое binfmt?

Функция ядра Linux binfmt позволяет запускать не ELF исполняемые файлы как исполняемые. К примеру, запускать скрипты python как бы как исполняемые файлы, а не интерпретируемые, бинарники для другой процессорной архитектуры через эмулятор Qemu запускать как бы как родные исполняемые файлы, аналогично запускать *.exe как бы как родные исполняемые файлы. Здесь неплохо описаны работа и использование binfmt.

Почему binfmt для *.exe — это потенциальная угроза безопасности?

Потому что мы таким образом внутри ОС приравняем виндовые исполняемые файлы *.exe к родным для линукса. Откроем возможность незаметно запустить вирус для Windows. Можно переименовать файл из xxx.exe в просто xxx в стиле исполняемых файлов Linux, у которых нет расширений, и запустить его (да, он запустится, потому что в конфиге binfmt файлы идентифицируются по содержимому, а не названию). В списке процессов на глаз сложно понять, что процесс xxx запущен через Wine.

Еще, например, можно написать правило AppArmor, чтобы он ограничивал функционал Wine, например, запрещая доступ к каким-то папкам для защиты от вирусов-шифровальщиков.

Пусть у нас нет binfmt для wine, а запускамая программа для Windows называется prog.exe. Тогда в списке процессов это будет так: /usr/bin/wine prog.exe. А если запустим через binfmt, вот так: ./prog.exe. Если binfmt выключен и/или скачанный *.exe не сделан исполняемым файлом, то, когда 21 раза нажмем на него в файловом менеджере, он откроется с помощью Wine (/usr/bin/wine prog.exe), как если открыть фильм с помощью какого-то плеера. А если у нас включен binfmt для wine, откроем свойства файла prog.exe и поставим галку «Является выполняемым» или сделаем chmod +x prog.exe, то при двойном клике на него он запустится как исполняемый файл сам по себе, а не откроется с помощью wine, то есть в списке процессов будет ./prog.exe. Это может быть актуально на корпоративных системах, где для чего-то установлен wine, но работникам не нужно мочь запускать неопнятно что из интернета или с флешки.

Так вот, AppArmor в первом случае применит правило для Wine, а во втором — правило для prog.exe. Получается, с помощью binfmt wine можно повысить безопасность, если для каждой прогарммы вручную написать свое правило AppArmor, однако в большинстве случае это дополнительный вектор атаки.

Еще, совсем теоретически, в браузере, почтовом клиенте или любой другой программе может найтись уязвимость, позволяющая удаленно выполнить код (файл) на компьютере жертвы. Уязвимость может работать и на Windows, и на Linux, но вот благодаря binfmt на Linux таким образом запустится код для Windows.

В общем, это такая штука, которая может быть полезной, но по умолчанию не должна быть включена.

Обсуждение велось в группе Росы вконтакте здесь (ссылка сохранена для истории).