Тред лучшей, на текущий момент, системы дистрибьюции и организации десктопных приложений в Linux.
Из коробки поддерживается и имеется поддержка в графическом центре приложений: Fedora (gnome-software), Solus, MX Linux, Linux Mint, KDE Neon.
Есть в репозиториях: Ubuntu (есть так же официальный PPA с более свежими версиями), Debian (старый), CentOS, ArchLinux, AlpineLinux (отсутствуют xdg-desktop-portal-), NixOS (порталы только xdg-desktop-portal-kde), GuixSD (отсутствуют xdg-desktop-portal-), VoidLinux (порталы только xdg-desktop-portal-gtk) и другие. Для Gentoo сторонний оверлей.
Порталы: утилиты для избирательного доступа к ресурсам хоста: файловые диалоги, запуск приложений, открытие ссылок и т.д. Сейчас существует две основных реализации: xdg-desktop-portal-gtk, xdg-dektop-portal-kde.
Чем лучше snap: Пофайловая дедупликация - занимает намного меньше места на диске и при обновлениях, быстрый запуск приложений. Изоляция через user namespaces (утилита bublewrap превосходящая firejail по безопасности), в snap для изоляции используется AppArmor и во многих приложениях она отключена.
Чем лучше AppImage: Изоляция изкоробки, в AppImage только при запуске через firejail, который ограничивает сравнительно мало. AppImage способствует порочной практике запуска исполняемых файлов загруженных из ненадежных источников. Лучшая интеграция в систему, которая будет улучшаться и дальше. Не зависит от состава дистрибутива: AppImage приложения непосредствено могут не работать в некоторых дистрибутивах, например в Alpine.
Стоит использовать: Для установки стороннего софта, которого нет в репозиториях. Для установки свежих версий софта, если в репозиториях дистра только старые. Вместо использования AUR. В некоторвых случаях, вместо пакетов из дистрибутива: например, для изоляции и сокрытия зависимостей.
Не стоит использовать: Если софт в репозиториях всем устраивает а дополнительная изоляция не нужна. Если конкретный flatpak бандл собран криво или изоляция ограничивает необходимую функциональность. При использовании архитектур, отличных от x86_64 и i386: на данный момент большая часть софта собрана только под них.
Для простых смертных. Серверное применение вообще не рассматривается, как цель. Даже если получится использовать, это будет извращение. Для серверов уже есть тысячи разных инструментов.
Алсо, вместо того чтобы пилить принципиально новый (тм) сандбокс который ещё нихуя не сандбоксит, можно было бы использовать существующие решения - firejail, xpra, appimage. Модифицировать пришлось бы, конечно, но работы-то меньше чем с нуля писать, соответственно и багов меньше.
запусти firejail --appimage и удивись. Он сэндбоксит ещё меньше, чем flatpak. Сайт flatkill.org - это типичный пример манипуляции подачей информации. Он рассказывает о недостатках изоляции отдельных бандлов для flatpak, но не говорит о проблемах изоляции в snap и firejail.
> Модифицировать пришлось бы, конечно, но работы-то меньше чем с нуля писать, соответственно и багов меньше.
Нет, bubblewrap концептуально лучше. Так там по умолчанию очень ограниченное окружение дается, и уже опциями дополнительные пути с хоста монтируются и становятся доступными. В firejail наоборот, по умолчанию много доступно, на отдельные пути блеклистятся. Кроме того, bubblewrap нигде не использует повышение привелегий, а в firejail многое требует рута, поверхность атаки больше. И ещё, сам по себе запуск firejail что-то-там ничего не значит. Важны конкретные профили, которые испльзуются. И если что-то не устраивает, придется писать свои профили, так же как и во flatpak можно переопределить разрешения предоставленные бандлом на свои. Можно даже глобально.
А вообще, те проблемы, на которые flatkill указывает, они берутся из необходимости использовать софт. --filesystem=host и --filesystem=home берутся из необходимости как-то предоставить доступ к ресурсам. Это в некоторой мере аналог confinement=classic в snap, хотя они не равноценны. Взять, к примеру, vim. Многие пользуются им для правки конфигов в /etc, и как же это сделать без доступа к /etc?
>>272 Пишешь >запусти firejail --appimage и удивись и я уже хочу возразить, но потом ты сам же пишешь >запуск firejail что-то-там ничего не значит. Важны конкретные профили, которые испльзуются.
>Взять, к примеру, vim. Многие пользуются им для правки конфигов в /etc, и как же это сделать без доступа к /etc? Так vim кто-то распостраняет через флатпак? По аналогии можно и огнелису не ограничивать доступ к файлам, а то вдруг юзер захочет открыть .html из произвольной папки. Ну и в чём тогда суть сандбокса вообще?
Так то что на flatkill написано, там то же самое. Не система изоляции плохая, а конкретные профили.
>По аналогии можно и огнелису не ограничивать доступ к файлам, а то вдруг юзер захочет открыть .html из произвольной папки. Ну и в чём тогда суть сандбокса вообще?
Сейчас вообще нет разницы между хорошей изоляцией и плохой изоляцией, она вся плохая. И не потому что системы изоляции плохие. Bubblewrap лучше, чем firejail, но грубо говоря они аналогичны и опираются на одни и те же фичи ядра. Можно хоть гипервизоры использовать, для большей безопасности, это не проблема. Но вся изоляция плохая в данном применении, потому что приходится балансировать между привычной работой приложений с доступом к ресурсам и изоляцией. Нужны протоколы доступа к ресурсам из sandbox'а, и они развиваются в xdg-desktop-portal. Но на текущий момент они крайне примитивны и далеко не все приложения умеют с ними работать. И те же порталы сейчас используются не только в flatpak, но и в snap и даже вне всякой изоляции. Идеальной изоляции не получится на пустом месте, она должа развиваться в условиях реального применения.
Вот выше пример с xpra - то же, дает изоляцию обходя небезопасность иксов, но ломает буфер обмена, например. Костылями его восстановить обратно можно, но это опять же требует создания таких костылей.
Какого-то специального инструмента для прокси там нет, все как и без флатпака. Но можно переопределять переменные окружения для каждого приложния индивидуально, и можно задать прокси через них.
>>2479 >Ололо, линуксоиды наконец смогли ставить любые приложения без ебли?
>>2520 > у приложения остаётся возможность какие-либо соединения в обход прокси устанавливать? Естественно. Для изоляции сети там должна быть включена поддержка network namespaces (если она есть в flatpak'е), между хостом и контейнером поднята сеть без роутинга вовне и на интерфейс этой сети со стороны хоста должен быть повешен прокси-сервер.
Да, имеется. Тут только полагаться на честную работу приложения.
>>2525 >поддержка network namespaces (если она есть в flatpak'е)
flatpak через network namespaces только изолировать от сети может. Потому что создать новый неймспейс с lo - это все что можно делать rootless, что он и делает при --unshare=network. Наверное можно запускать и с произвольным своим заранее настроенным неймспейсом, но на стороне флатпака опций для этого не предусмотрено.
>>2530 > Тут только полагаться на честную работу приложения. Что за хрень ты написал? Если приложение не поддерживает работу через http-прокси и потому игнорирует соответствующую переменную среды — это честная работа или нет? Потом, даже если приложение умеет http-прокси, то это ещё не значит, что при его работе не будет прямых обращений в инет: вызываемые им в процессе работы программы и динамические библиотеки могут это и не уметь.
И потом, мне кажется, вопрос был как раз про потенциальную «нечестность» приложения.
> на стороне флатпака опций для этого не предусмотрено. Ну т.е. при его использовании остаётся только обмазываться фаерволом, что потенциально дыряво, т.к. приложение может утечь по не предусмотренному фаерволом протоколу — например, dns-туннелем через dbus и systemd-resolved.