Разрешения песочницы

Одна из основных целей Flatpak - повысить безопасность настольных систем за счет изоляции приложений друг от друга. Это достигается с помощью песочницы и означает, что по умолчанию приложения, запускаемые с Flatpak, имеют чрезвычайно ограниченный доступ к среде хоста. Это включает:

  • Нет доступа к каким-либо файлам хоста, кроме среды выполнения, приложения, ~/.var/app/$FLATPAK_ID, and $XDG_RUNTIME_DIR/app/$FLATPAK_ID. Только два последних доступны для записи.

  • Нет доступа к сети.

  • Нет доступа к каким-либо узлам устройства (кроме /dev/null, etc).

  • Нет доступа к процессам вне песочницы.

  • Ограниченные счета. Например, приложения не могут использовать нестандартные типы сетевых сокетов или отслеживать другие процессы ptrace.

  • Ограниченный доступ к экземпляру сеанса D-Bus - приложение может владеть только собственным именем на шине.

  • Нет доступа к хост-службам, таким как X11, системный D-Bus или PulseAudio.

Большинству приложений, чтобы быть полезными, потребуется доступ к некоторым из этих ресурсов. В первую очередь это делается на этапе завершающей сборки, который можно настроить в разделе finish-args файла манифеста (см. manifestests).

Порталы

Порталы уже упоминались в Основные понятия. Они представляют собой основу для предоставления доступа к ресурсам за пределами песочницы, в том числе:

  • Открытие файлов с помощью собственного диалогового окна выбора файлов

  • Открытие URIs

  • Печать

  • Отображение уведомлений

  • Снятие скриншотов

  • Запрет пользовательского сеанса на завершение, приостановку, простой или отключение

  • Получение информации о состоянии сети

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

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

Interface toolkits like GTK3 and Qt5 implement transparent support for portals, meaning that applications don’t need to do any additional work to use them (it is worth checking which portals each toolkit supports). Applications that aren’t using a toolkit with support for portals can refer to the xdg-desktop-portal API documentation for information on how to use them.

Рекомендации по разрешениям

Хотя разработчики приложений имеют контроль над разрешениями песочницы, которые они хотят настроить, рекомендуется применять передовые методы, которые могут применяться. Например, служба хостинга Flathub предъявляет требования к тому, какие разрешения могут использоваться, а программное обеспечение на хосте может предупреждать пользователей, если используются определенные разрешения.

Следующие рекомендации описывают, какие разрешения можно использовать свободно, какие можно использовать по мере необходимости, а каких следует избегать.

Стандартные разрешения

Следующие разрешения обеспечивают доступ к основным ресурсам, которые обычно требуются приложениям и поэтому могут быть свободно использованы:

  • --share=network - доступ к сети

  • --socket=x11 - показать окна с помощью X11

  • --socket=fallback-x11 - показывать окна с использованием X11, если Wayland недоступен, переопределяет разрешение сокета x11. Обратите внимание, что вы все равно должны использовать --socket=wayland для разрешения wayland

  • --share=ipc - совместно использовать пространство имен IPC с хостом (необходимо для X11)

  • --socket=wayland - показать окна Wayland

  • --device=dri - отрисовка OpenGL

  • --socket=pulseaudio - воспроизводить звук с PulseAudio

Доступ к D-Bus

Следует избегать доступа ко всей шине с помощью --socket=system-bus или --socket=session-bus если только приложение не является инструментом разработки.

Право собственности

Приложениям автоматически предоставляется доступ к их собственному пространству имен. Право собственности сверх этого обычно не требуется, хотя есть небольшое количество исключений, таких как использование MPRIS для обеспечения управления мультимедиа.

Разговор

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

Доступ к файловой системе

Обычно приложениям требуется доступ к разным частям файловой системы хоста, и Flatpak предоставляет для этого гибкий набор опций. Вот некоторые примеры:

  • --filesystem=host - доступ к обычным файлам на хосте, за исключением операционной системы хоста или внутренних систем, описанных ниже

  • --filesystem=home - доступ к домашнему каталогу пользователя

  • --filesystem=/path/path - доступ к определенным путям

  • --filesystem=xdg-download - доступ к определенной папке XDG

Как правило, доступ к файловой системе должен быть максимально ограничен. Это включает:

  • Использование порталов в качестве альтернативы общему доступу к файловой системе везде, где это возможно.

  • Использование доступа только для чтения везде, где это возможно, с использованием параметра :ro.

  • Если точно необходим доступ к домашнему каталогу, используйте только доступ к каталогу XDG.

Полный список доступных параметров файловой системы можно найти в Разрешения песочницы. Другие правила доступа к файловой системе включают:

  • Параметр --persist=path может использоваться для отображения путей из домашнего каталога пользователя в файловую систему песочницы. Это позволяет избежать настройки доступа ко всему домашнему каталогу и может быть полезно для приложений, которые жестко шифруют пути к файлам в ~/.

  • Если приложение использует $TMPDIR , чтобы содержать файлы блокировки, вы можете добавить скрипт обертки, который устанавливает его на $XDG_RUNTIME_DIR/app/$FLATPAK_ID.

  • Сохранение и совместное использование конфигурация с установкой отличной от Flatpak следует избегать.

Как упоминалось выше, опция host фактически не обеспечивает полный доступ к файловой системе хоста. Основные правила:

  • Эти каталоги занесены в черный список: /lib, /lib32, /lib64, /bin, /sbin, /usr, /boot, /root, /tmp, /etc, /app, /run, /proc, /sys, /dev, /var

  • Исключения из черного списка: /run/media

  • Эти каталоги смонтированы в /var/run/host: /etc, /usr

Причина, по которой многие каталоги занесены в черный список, заключается в том, что они уже существуют в песочнице, например, /usr или не могут использоваться в песочнице.

Разрешение home также имеет исключения, поскольку оно не предоставляет доступ к подкаталогам для других приложений в ~/.var/app/.

Доступ к устройству

Хотя это и не совсем хорошо, --device=all можно использовать для доступа к таким устройствам, как контроллеры или веб-камеры.

доступ к dconf

По состоянию на xdg-desktop-portal 1.1.0 и glib 2.60.5 (во время выполнения) вам не нужен прямой доступ DConf в большинстве случаев.

На данный момент эта версия glib включена в org.freedesktop.Platform//19.08 and org.gnome.Platform//3.34 и новее.

Если приложение существовало до этих runtimes, вы можете сообщить flatpak (>= 1.3.4), чтобы перенести настройки DConf на хосте в песочницу, добавив --metadata=X-DConf=migrate-path=/org/example/foo/ в finish-args. Путь должен быть похож на ваше ID приложения или его не допущено (случай игнорируется и _ и - , обработанные одинаково).

Если вы нацеливаете более старые runtimes или требуют прямых доступа DConf по другим причинам, вы можете использовать эти разрешения:

--filesystem=xdg-run/dconf
--filesystem=~/.config/dconf:ro
--talk-name=ca.desrt.dconf
--env=DCONF_USER_CONFIG_DIR=.config/dconf

С этими разрешениями glib продолжит использовать dconf напрямую.

If you use a newer runtime where dconf is no longer built and still need it you will have to build the dconf GIO module and set --env=GIO_EXTRA_MODULES=/app/lib/gio/modules/.

gvfs-доступ

Начиная с gvfs 1.48, демоны и приложения gvfs используют для связи сокет на диске, а не абстрактный сокет, поэтому инфраструктура gvfs продолжает работать, когда поддержка сети отключена в изолированной программной среде приложения.

В зависимости от того, как приложение использует gvfs, необходимо передать ряд различных параметров.

--talk-name=org.gtk.vfs.* необходим для связи с демонами gvfs через D-Bus и составления списка подключений с использованием GIO APIs.

--filesystem=xdg-run/gvfsd необходимо использовать API-интерфейсы GIO для просмотра и доступа к неродным файлам с использованием API-интерфейсов GIO, используя URL-адреса, а не пути FUSE.

--filesystem=xdg-run/gvfs необходим для предоставления доступа к монтированию FUSE, которое могут использовать не-GIO и устаревшие приложения. Это то, что заставит родные файлы появиться в /run/user/`id -u`/gvfs/.

Типичные приложения GNOME и GTK должны использовать:

--talk-name=org.gtk.vfs.*
--filesystem=xdg-run/gvfsd

Типичные приложения, отличные от GNOME и GTK, должны использовать:

--filesystem=xdg-run/gvfs

Ни одно приложение не должно использовать --talk-name=org.gtk.vfs в своем манифесте, так как нет сервисов D-Bus с именем org.gtk.vfs.