Permissões de sandbox

Um dos principais objetivos do Flatpak é aumentar a segurança dos sistemas de desktop, isolando os aplicativos uns dos outros. Isso é alcançado usando sandbox e significa que, por padrão, os aplicativos executados com o Flatpak têm acesso extremamente limitado ao ambiente host. Isso inclui:

• Sem acesso a nenhum arquivo host, exceto o runtime, o aplicativo e ~/.var/app/$FLATPAK_ID e $XDG_RUNTIME_DIR/app/$FLATPAK_ID. Apenas o último deles pode ser escrito.

• Sem acesso à rede.

• Sem acesso a nenhum nó do dispositivo (além de /dev/null, etc).

• Sem acesso a processos fora do sandbox.

• Chamadas de sistema limitados. Por exemplo, os aplicativos não podem usar tipos de soquete de rede fora do padrão ou rastrear outros processos.

• Acesso limitado à instância do D-Bus da sessão – um aplicativo pode possuir apenas seu próprio nome no barramento.

• Sem acesso a serviços de host como X11, D-Bus do sistema ou PulseAudio.

A maioria dos aplicativos precisará acessar alguns desses recursos para ser útil. Isso é feito principalmente durante o estágio de compilação de acabamento, que pode ser configurado através da seção finish-args do arquivo de manifesto (consulte Manifestos).

Portais

Os portais já foram mencionados em Conceitos básicos. Eles são um framework para fornecer acesso a recursos fora da área isolada, incluindo:

• Abertura de arquivos com um diálogo nativo de seleção de arquivos

• Abertura de URLs

• Impressão

• Mostrar notificações

• Obtenção de capturas de tela

• Inibir que a sessão do usuário seja encerrada, suspensa, fique inativa ou seja trocada

• Obtendo informações de status da rede

Em muitos casos, portais usam um componente do sistema para pedir implicitamente permissão ao usuário antes de conceder acesso a um recurso específico. Por exemplo, no caso de abrir um arquivo, a seleção de um arquivo pelo usuário usando a caixa de diálogo do seletor de arquivos é interpretada como concedendo implicitamente ao aplicativo o acesso a qualquer arquivo escolhido.

Essa abordagem permite que os aplicativos evitem configurar o acesso geral a grandes quantidades de dados ou serviços e oferece aos usuários controle sobre o que seus aplicativos têm acesso.

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.

Diretrizes de permissões

Embora os desenvolvedores de aplicativos tenham controle sobre as permissões do sandbox que desejam configurar, as boas práticas são incentivadas e podem ser aplicadas. Por exemplo, o serviço de hospedagem Flathub impõe requisitos nos quais as permissões podem ser usadas, e o software no host pode avisar os usuários se determinadas permissões forem usadas.

As diretrizes a seguir descrevem quais permissões podem ser usadas livremente, quais podem ser usadas conforme a necessidade e quais devem ser evitadas.

Permissões padrão

As seguintes permissões fornecem acesso aos recursos básicos que os aplicativos geralmente exigem e, portanto, podem ser usados livremente:

• --allow=bluetooth - Allow access to Bluetooth

• --device=dri – renderização 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 – mostra janelas usando X11

• --socket=fallback-x11 - mostra janelas usando X11, se Wayland não estiver disponível, substitui a permissão de soquete x11. Observe que você ainda deve usar --socket=wayland para permissão de wayland

Acesso a 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.

Propriedade

Os aplicativos recebem acesso automaticamente ao seu próprio espaço de nome. A propriedade além disso é normalmente desnecessária, embora haja um pequeno número de exceções, como o uso de MPRIS para fornecer controles de mídia.

Conversa

As permissões de conversa podem ser usadas livremente, embora seja recomendável usar o mínimo necessário.

Acesso ao sistema de arquivos

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

• Usar portais como uma alternativa ao acesso geral ao sistema de arquivos, sempre que possível

• Usar acesso somente leitura sempre que possível, usando a opção :ro.

• Se for absolutamente necessário algum acesso à pasta pessoal do usuário, usar apenas o acesso ao diretório 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 all files [3]
host-etc	Access all files in host and host’s /etc [3]
home	Access the home directory [4]
/some/dir	Access an arbitrary path [5] [6]
~/some/dir	Access an arbitrary path relative to the home directory [6]
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 [7]	$XDG_CONFIG_HOME or $HOME/.config
xdg-cache	Access the XDG cache directory [7]	$XDG_CACHE_HOME or $HOME/.cache
xdg-data	Access the XDG data directory [7]	$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)

Note that host, host-etc, host-os mounts the host directories under /run/host inside the sandbox to avoid conflict with the runtime.

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:

• A opção --persist=path pode ser usada para mapear caminhos do diretório inicial do usuário para o sistema de arquivos sandbox. Isso torna possível evitar a configuração do acesso a todo o diretório pessoal e pode ser útil para aplicativos que codificam os caminhos do arquivo em ~/.

• Se um aplicativo usa $TMPDIR para conter arquivos de trava, você pode querer adicionar um script wrapper que o defina como $XDG_RUNTIME_DIR/app/$FLATPAK_ID.

• Reter e compartilhar a configuração com instalações que não sejam do Flatpak deve ser evitado.

Acesso a dispositivo

Embora não seja o ideal, --device=all pode ser usado para acessar dispositivos como controladores ou webcams.

Acesso a dconf

No xdg-desktop-portal 1.1.0 e glib 2.60.5 (no runtime), você não precisa de acesso direto ao DConf na maioria dos casos.

A partir de agora, esta versão do glib está incluída em org.freedesktop.Platform//19.08 e org.gnome.Platform//3.34 e mais novos.

Se um aplicativo existia antes desses runtimes, você pode dizer ao Flatpak (>= 1.3.4) para migrar as configurações do DConf no host para o sandbox, adicionando --metadata=X-DConf=migrate-path=/org/exemplo/foo/ para finish-args. O caminho deve ser semelhante ao seu ID de aplicativo ou não será permitido (não diferencia maiúsculo de minúsculo, e _ e `` -`` são tratados da mesma forma).

Se você estiver direcionando runtimes mais antigos ou precisar de acesso direto ao DConf por outros motivos, poderá usar estas permissões:

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

Com essas permissões, o glib continuará usando o dconf diretamente.

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/.

Acesso a gvfs

A partir do gvfs 1.48, os daemons e aplicativos do gvfs usam um soquete no disco para se comunicar, em vez de um soquete abstrato, para que a infraestrutura do gvfs ainda funcione quando o suporte à rede estiver desabilitado no isolamento do aplicativo.

Várias opções diferentes precisam ser passadas dependendo do uso de gvfs do aplicativo.

--talk-name=org.gtk.vfs.* é necessário para falar com os daemons do gvfs sobre D-Bus e listar montagens usando as APIs do GIO.

--filesystem=xdg-run/gvfsd é necessário usar as APIs do GIO para listar e acessar arquivos não nativos usando as APIs do GIO, usando URLs em vez de caminhos FUSE.

--filesystem=xdg-run/gvfs é necessário para dar acesso às montagens FUSE não-GIO e aplicativos legados podem usar. Isto é o que fará com que os arquivos nativos apareçam em /run/user/`id -u`/gvfs/.

Os aplicativos GNOME e GTK típicos devem usar:

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

Os aplicativos não-GNOME e não-GTK típicos devem usar:

--filesystem=xdg-run/gvfs

Nenhum aplicativo deve usar --talk-name=org.gtk.vfs em seu manifesto, pois não há serviços D-Bus chamados org.gtk.vfs.

Footnotes

[1]

This is not necessarily required, but without it the X11 shared memory extension will not work, which is very bad for X11 performance.

[2]

Giving network access also grants access to all host services listening on abstract Unix sockets (due to how network namespaces work), and these have no permission checks. This unfortunately affects e.g. the X server and the session bus which listens to abstract sockets by default. A secure distribution should disable these and just use regular sockets.

[3] (1,2)

Except for /app, /bin, /boot, /efi, /etc, /lib, /lib32, /lib64, /proc, /root, /run, /sbin, /tmp, /usr, /var

[4]

This does not include access to folders under ~/.var/app except the application’s own

[5]

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

[6] (1,2)

The arbitrary path includes all its subfolders and subfiles if any.

[7] (1,2,3)

xdg-{cache, config, data} binds mount the paths from host to the per-app sandbox directory. Inside the sandbox $XDG_CACHE_HOME, $XDG_CONFIG_HOME and $XDG_DATA_HOME is set to $HOME/.var/app/<app-id>/{cache, config, data}. So this permission is not needed unless access to the host directory, bind mounted to $HOME/.var/app/<app-id>/{cache, config, data} is desired.