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

Одна из основных целей 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 предъявляет требования к тому, какие разрешения могут использоваться, а программное обеспечение на хосте может предупреждать пользователей, если используются определенные разрешения.

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

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

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

  • --allow=bluetooth - Allow access to Bluetooth

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

  • --device=input - Access to /dev/input

  • --share=ipc - share IPC namespace with the host [1]

  • --share=network - access the network [2]

  • --socket=cups - Talk to the CUPS printing system

  • --socket=gpg-agent - Talk to the GPG agent

  • --socket=pcsc - Smart card access

  • --socket=pulseaudio - Play sound with PulseAudio

  • --socket=ssh-auth- Allow access to SSH_AUTH_SOCK

  • --socket=wayland - Show windows with Wayland

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

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

Примечание

Applications that do not support native Wayland should use --socket=x11 and applications that do should use --socket=fallback-x11 and --socket=wayland. The two configurations here will make it work on both X11 and Wayland sessions of the desktop environment.

Доступ к D-Bus

Access to the entire bus with --socket=system-bus or --socket=session-bus is a security risk and must be avoided, unless the application is a development tool.

flatpak run --log-session-bus <appid> can be used to find the specific D-Bus permissions needed.

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

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

Разговор

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

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

As a general rule, static and permanent filesystem access should be limited as much as possible. This includes:

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

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

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

The following permission options are available:

  • :ro - read-only access

  • :create - read/write access, and create the directory if it doesn’t exist

Additionally the following permissions are available:

host

Access to /home, /media, /opt, /run/media, /srv and everything provided by host-os, host-etc mounted in /run/host

Includes any subpaths

host-etc

Host’s /etc

Host’s /etc is mounted at /run/host/etc

host-os

Host’s /usr, /bin, /sbin, /lib{32, 64}, /etc/ld.so.cache, /etc/alternatives

Mounted at /run/host

home

Access the home directory

Except ~/.var/app

/some/dir

Access an arbitrary path except any reserved path

Includes any subpaths

~/some/dir

Arbitrary path relative to the home directory

Includes any subpaths

xdg-desktop

Access the XDG desktop directory

$XDG_DESKTOP_DIR or $HOME/Desktop

xdg-documents

Access the XDG documents directory

$XDG_DOCUMENTS_DIR or $HOME/Documents

xdg-download

Access the XDG download directory

$XDG_DOWNLOAD_DIR or $HOME/Downloads

xdg-music

Access the XDG music directory

$XDG_MUSIC_DIR or $HOME/Music

xdg-pictures

Access the XDG pictures directory

$XDG_PICTURES_DIR or $HOME/Pictures

xdg-public-share

Access the XDG public directory

$XDG_PUBLICSHARE_DIR or $HOME/Public

xdg-videos

Access the XDG videos directory

$XDG_VIDEOS_DIR or $HOME/Videos

xdg-templates

Access the XDG templates directory

$XDG_TEMPLATES_DIR or $HOME/Templates

xdg-config

Access the XDG config directory [3]

$XDG_CONFIG_HOME or $HOME/.config

xdg-cache

Access the XDG cache directory [3]

$XDG_CACHE_HOME or $HOME/.cache

xdg-data

Access the XDG data directory [3]

$XDG_DATA_HOME or $HOME/.local/share

xdg-run/path

Access subdirectories of the XDG runtime directory

$XDG_RUNTIME_DIR/path (/run/user/$UID/path)

Except host, host-etc, host-os paths can be added to all the above filesystem options. For example, --filesystem=xdg-documents/path.

Other filesystem access guidelines include:

  • The --persist=DIR option can be used to map directories from the user’s home directory into the sandbox filesystem. This only works if the application has no home or a broader permission like host that includes home.

    For example, if an application hardcodes the directory ~/.foo, without any home access and no --persist the directory will be lost from the sandbox once exited due to the filesystem being set up as tmpfs by flatpak unless overriden. A --persist=.foo bind mounts ~/.foo inside the sandbox to ~/.var/app/$FLATPAK_ID/.foo on host thus allowing an app to persistently store data in ~/.var/app/$FLATPAK_ID/.foo which would otherwise be lost.

    A --persist=. will persist all directories.

    This does not support :create, :ro, :rw suffixes or special values like xdg-documents. However, the directory will be created by flatpak if it doesn’t already exist.

    This makes it possible to avoid configuring access to the entire home directory, and can be useful for applications that hardcode file paths in ~/.

  • If an application uses $TMPDIR to contain lock files you may want to add a wrapper script that sets it to $XDG_RUNTIME_DIR/app/$FLATPAK_ID (tmpfs) or /var/tmp (persistent on host).

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

Reserved Paths

The following paths are reserved for the runtime and Flatpak itself and are never shared:

/app, /bin, /dev, /etc, /lib, /lib32, /lib64, /proc, /run, /run/flatpak, /run/host, /sbin, /usr

Some subpaths of /run are allowed but not the entire directory.

Additionally the following directories from host need to be explicitly requested with --filesystem and are not available with home, host, host-os, host-etc by default:

  • ~/.var/app - The app can access only its own directory in ~/.var/app/$FLATPAK_ID

  • $XDG_DATA_HOME/flatpak (~/.local/share/flatpak)

  • /boot

  • /efi

  • /root

  • /sys

  • /tmp

  • /var - Note that by default /var/{cache, config, data, tmp} inside the sandbox are the same as ~/.var/app/$FLATPAK_ID/{cache, config, data, cache/tmp}. However an explicit --filesystem=/var will make only /var from host available and those will no longer be available.

  • /var/lib/flatpak - /var does not give access to this.

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

Хотя это и не совсем хорошо, --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.

External drive access

External drives are mounted by the host system using systemd, udev, udisk fstab etc. and each of them can have different defaults. Flatpak has no control over how and where they get mounted. The following filesystem permissions should work in most cases:

--filesystem=/media
--filesystem=/run/media
--filesystem=/mnt

If --filesystem=host is used /media, /run/media is shared automatically if they exist.

Note that these should not have subpaths in them unless the value of the subpath can be consistently pre-determined. Block device naming depends on the kernel/fstab configuration and cannot be pre-determined.

Footnotes