Релизът на системата за самостоятелни пакети Flatpak 1.12.0

Публикувана е нова стабилна версия на инструмента Flatpak 1.12, който предоставя система за изграждане на самостоятелни пакети, независими от конкретни дистрибуции на Linux и изпълнявани в специален контейнер, изолиращ приложението от останалата част на системата. Поддръжката за изпълнение на Flatpak-пакети е осигурена за Arch Linux, CentOS, Debian, Fedora, Gentoo, Mageia, Linux Mint, Alt Linux и Ubuntu. Пакетите с Flatpak са включени в репозитория на Fedora и се поддържат в стандартната програма за управление на приложения GNOME.

Ключови нововъведения в версията Flatpak 1.12:

• Подобрено е управлението на вложените sandbox-окружения, използвани в flatpak-пакета с клиент за услугата за доставка на игри Steam. В вложените sandbox-и е разрешено създаването на отделни йерархии на директории /usr и /app, което се използва в Steam за стартиране на игри в отделен контейнер със собствено разделение /usr, изолирано от околната среда с клиента Steam.
• Във всички екземпляри на пакети с един и същ идентификатор на приложението (app-ID) е осигурено споделянето на директориите /tmp и $XDG_RUNTIME_DIR. По желание с флага "--allow=per-app-dev-shm" може да се включи използването на споделена директория /dev/shm.
• Подобрена е поддръжката на приложения с текстов потребителски интерфейс (TUI), като gdb.
• В утилитата build-update-repo е добавена по-бърза реализация на команда "ostree prune", оптимизирана за работа с репозитории, намиращи се в режим на архив.
• Устранена е уязвимост CVE-2021-41133 в реализирането на механизма за портали, свързана с липсата в правилата seccomp за блокиране на нови системни повиквания, свързани с монтиране на дялове. Уязвимостта е позволявала на приложението да създаде вложен sandbox, за да заобиколи механизмите за верификация на "порталите", които се използват за организиране на достъп до ресурси извън контейнера.

  В резултат на това, атакуващият чрез изпълнението на свързани с монтиране системни повиквания е могъл да заобиколи механизма на sandbox-изолацията и да получи пълен достъп до съдържанието на хост-околната среда. Експлоатацията на уязвимостта е възможна само в пакети, които предоставят на приложенията директен достъп до сокети AF_UNIX, които например, се използват в Wayland, Pipewire и pipewire-pulse. В изданието 1.12.0 уязвимостта не е била напълно отстранена, затова веднага след това е издадено актуализиране 1.12.1.

Напомняме, че Flatpak предоставя на разработчиците на приложения възможност да опростят разпространението на своите програми, които не влизат в стандартните репозитории на дистрибуциите, чрез подготовка на един универсален контейнер, без необходимост от създаване на отделни версии за всяка дистрибуция. Flatpak позволява на потребителите, които се грижат за сигурността, да изпълняват подозрителни приложения в контейнер, давайки достъп само до мрежови функции и файлове на потребителя, свързани с приложението. За потребителите, които се интересуват от нови неща, Flatpak позволява инсталирането на най-новите тестови и стабилни версии на приложения без необходимост от промени в системата. Например, Flatpak пакети са на разположение за LibreOffice, Midori, GIMP, Inkscape, Kdenlive, Steam, 0 A.D., Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio и др.

За да се намали размерът на пакета, той включва само специфични за приложението зависимости, докато основните системни и графични библиотеки (GTK, Qt, библиотеки GNOME и KDE и т.н.) са организирани под формата на модулни типови runtime среди. Ключовата разлика между Flatpak и Snap е, че Snap използва компоненти на основната система и изолация на базата на филтриране на системни повиквания, докато Flatpak създава отделен от системата контейнер и работи с големи набори от runtime, предоставяйки типови системни среди като зависимости, а не пакети (например всички библиотеки, необходими за работа на приложения GNOME или KDE).

Освен типичната системна среда (runtime), инсталирана чрез специален репозиторий, се доставят допълнителни зависимости (bundle), необходими за работата на приложението. В сумата runtime и bundle образуват съдържанието на контейнера, като едновременно runtime се инсталира самостоятелно и се свързва с няколко контейнера, което позволява да се избегне дублирането на общи за контейнерите системни файлове. В една система могат да бъдат инсталирани различни runtime (GNOME, KDE) или различни версии на един и същи runtime (GNOME 3.40, GNOME 3.42). Контейнерът с приложението, като зависимост, използва свързването само със специфичен runtime, без да отчита отделните пакети, от които се състои runtime. Всички липсващи елементи се опаковат директно заедно с приложението. При формироването на контейнера, съдържанието на runtime се монтира като том на /usr, а bundle се монтира в директория /app.

Съдържанието на runtime и контейнерите на приложенията се формира с използването на технологията OSTree, при която образът се актуализира атомарно от Git-подобно хранилище, позволяващо прилагането на методи за контрол на версиите към компонентите на дистрибуцията (например, системата може бързо да бъде възстановена до предишно състояние). RPM пакетите се трансформират в репозитория OSTree чрез специален слой rpm-ostree. Отделно инсталиране и обновление на пакети в работната среда не се поддържа, системата се обновява не на ниво отделни компоненти, а изцяло, атомарно променяйки своето състояние. По предоставени средства за инкрементално прилагане на актуализации, се освобождава от необходимостта от пълна подмяна на образа при всяко обновление.

Формираното изолирано обкръжение е напълно независимо от използвания дистрибутив и при подходящи настройки на пакета няма достъп до файловете и процесите на потребителя или основната система, не може директно да взаимодейства с оборудването, с изключение на извода чрез DRI и запитванията към мрежовата подсистема. Изводът на графиката и организацията на входа са реализирани с помощта на протокола Wayland или чрез пробив на сокета X11. Взаимодействието с външна среда е изградена на базата на система за обмен на съобщения DBus и специален API Portals.

За изолация се използва прослойка Bubblewrap и традиционни технологии за контейнерна виртуализация в Linux, базирани на използването на cgroups, пространства от имена (namespaces), Seccomp и SELinux. За изхода на звука се използва PulseAudio. В същото време изолацията може да бъде деактивирана, което разработчиците на много популярни пакети използват, за да получат пълен достъп до ФС и всички устройства в системата. Например, пакети с ограничен режим на изолация, който оставя пълен достъп до домашната директория, се предлагат за GIMP, VSCodium, PyCharm, Octave, Inkscape, Audacity и VLC.

В случай на компрометиране на пакети с достъп до домашната директория, въпреки наличието на етикет „sandboxed“ в описанието на пакета, атакуващият може да изпълни своя код, само като промени файла ~/ .bashrc. Отделен въпрос е контролът върху промените в пакетите и доверието към сборщиците на пакети, които често не са свързани с основния проект или дистрибуции.

Източник: opennet.ru