Flatpak runs applications in a sandbox built from the same kernel features containers use: namespaces, seccomp filters, and bind mounts. The application sees a constructed filesystem containing its runtime and its own data, not your system.

That is the design. Whether it protects you depends entirely on what permissions the application requested, and a large number of published Flatpaks request enough to make the sandbox mostly decorative.

Seeing what an application can do

flatpak info --show-permissions org.gimp.GIMP

[Context]
shared=network;ipc;
sockets=x11;wayland;
devices=dri;
filesystems=host;xdg-config/GIMP:create;

Read that carefully. filesystems=host means the application can read and write your entire filesystem. The sandbox is running, and it is not confining anything that matters.

The values to recognise:

Value	What it grants
host	The entire filesystem
home	Your whole home directory
xdg-documents	Just ~/Documents
xdg-download:ro	~/Downloads, read-only
~/Projects	One specific path

The :ro and :create suffixes control read-only and create-if-missing.

Why home access is the problem

People see filesystem=home and think it sounds reasonable, because the application only gets “their files”.

Consider what is in your home directory:

~/.ssh/id_ed25519          your private SSH keys
~/.gnupg/                  your GPG keys
~/.config/                 tokens and credentials for everything
~/.mozilla/                browser profile, saved sessions, cookies
~/.bash_history            commands, sometimes including secrets
~/.aws/credentials         cloud keys
~/.kube/config             cluster access

An application with home access can read all of it and, given network access, send it anywhere. Your system binaries are protected; the things an attacker actually wants are not.

This is the gap between the sandbox being technically present and the sandbox being useful, and it is what the 508,000 euro funding round is aimed at addressing.

Portals: the mechanism that makes narrow permissions work

If applications cannot read your filesystem, how do they open files?

Portals. A portal is a D-Bus service running outside the sandbox that performs an action on the application’s behalf.

When a sandboxed application opens a file:

1. It asks the file chooser portal for a file.
2. The portal displays the dialog, running outside the sandbox with full filesystem access.
3. You pick a file.
4. The portal hands the application a file descriptor for that one file.

The application never gets filesystem permission. It gets one file, because you chose it. This is the right model, and it is why an application built around portals can run with essentially no filesystem access and still work normally.

Portals also cover screenshots and screen recording, printing, opening URIs, camera and microphone, location, and background running.

ls /usr/share/xdg-desktop-portal/portals/

Each desktop needs its backend: xdg-desktop-portal-gnome, -kde, or -wlr for wlroots compositors. A missing backend is the most common reason screen recording fails on Wayland, and the symptom is a permission dialog that never appears.

Restricting an application yourself

You are not stuck with what the developer requested.

# remove home access entirely
flatpak override --user --nofilesystem=home org.example.App

# grant one directory back
flatpak override --user --filesystem=~/Documents org.example.App

# remove network access
flatpak override --user --unshare=network org.example.App

# see what you have overridden
flatpak override --user --show org.example.App

# start over
flatpak override --user --reset org.example.App

--user applies to your account; without it you are changing it system-wide and need root.

Overrides persist across application updates, which is what makes them worth setting.

Flatseal does the same thing with a graphical interface and is considerably easier for going through your installed applications one at a time:

flatpak install flathub com.github.tchx84.Flatseal

A sensible tightening pass

Worth doing once:

# what is installed and what does each want
for app in $(flatpak list --app --columns=application); do
  echo "=== $app"
  flatpak info --show-permissions "$app" | grep -E 'filesystems|shared|devices'
done

Then, for each application, ask what it genuinely needs.

A media player needs read access to your media directory and nothing else. No network, no home.

flatpak override --user --nofilesystem=home --unshare=network org.videolan.VLC
flatpak override --user --filesystem=~/Videos:ro org.videolan.VLC

An image editor can usually work through portals alone.

flatpak override --user --nofilesystem=host --nofilesystem=home org.gimp.GIMP

A browser needs network and quite a lot else. There is limited value in confining it heavily, and it has its own internal sandbox that is considerably stronger than Flatpak’s.

Expect some breakage. An application that genuinely needed the access will fail, sometimes with a clear error and sometimes by silently not seeing files. Reset and reconsider if so.

The weak points

Being honest about what the sandbox does not solve.

X11 offers no isolation at all. Under X11 any application with display access can read every other window’s keystrokes and contents. No sandbox can prevent this; it is how X11 works. This is one of the practical arguments for Wayland, which GNOME made its only default session this year.

# prefer Wayland where the app supports it
flatpak override --user --nosocket=x11 --socket=wayland org.example.App

Session bus access is broad. --socket=session-bus lets an application talk to every service on your D-Bus session, some of which can launch processes outside the sandbox. Narrow rules are better:

flatpak override --user --nosocket=session-bus org.example.App
flatpak override --user --talk-name=org.freedesktop.Notifications org.example.App

--device=all includes more than you think. Cameras, microphones, and input devices. --device=dri for graphics acceleration alone is usually what an application actually needs.

The runtime needs updating too. Flatpak applications bundle libraries via runtimes. An unpatched runtime is unpatched libraries.

flatpak update
flatpak uninstall --unused        # remove old runtimes still on disk

Flatpak against native packages

The comparison people want.

A native .deb or .rpm runs with your full user privileges and no confinement whatsoever. It can read anything you can read.

A well-confined Flatpak is meaningfully more restricted than that.

A Flatpak with filesystem=host and session bus access is roughly equivalent to a native package, with the added consideration that Flathub applications are frequently packaged by third parties rather than by your distribution’s maintainers.

So the security argument for Flatpak is conditional. It is real when permissions are narrow and largely illusory when they are not, and checking which situation you are in takes one command.

Our Snap, Flatpak, and AppImage comparison covers the wider tradeoffs between the formats.

Frequently Asked Questions

How do I see what permissions a Flatpak app has?

Run flatpak info —show-permissions followed by the application ID. This prints the filesystem access, device access, D-Bus names, and shared namespaces the application requested. Flatseal provides the same information in a graphical interface and lets you change it.

Does filesystem=home break the Flatpak sandbox?

It removes most of its value. An application with home access can read your SSH private keys, browser profiles, shell history, and every document you own, which covers nearly everything worth stealing. The process is still confined from the rest of the system, but the confinement no longer protects your data.

What are portals in Flatpak?

Portals are D-Bus services that let a sandboxed application request something outside its sandbox through a trusted intermediary. When an app opens a file chooser, the portal runs the dialog outside the sandbox and passes back access to only the file you selected, so the app never needs broad filesystem permission.

Can I make a Flatpak more restricted than the developer set it?

Yes. Use flatpak override to remove permissions, such as flatpak override —user —nofilesystem=home followed by the app ID. Flatseal does the same thing graphically. Overrides persist across updates, and the application may break if it genuinely needed the access.

Is Flatpak more secure than a distribution package?

It depends on the permissions. A well-confined Flatpak is considerably more restricted than a native package, which runs with your full user privileges and no confinement at all. A Flatpak with home and session bus access is roughly equivalent to a native package in practical terms.

Why does a Flatpak app need session bus access?

The D-Bus session bus is how desktop applications talk to each other and to desktop services for notifications, media keys, and similar integration. Unrestricted access to it is a known weak point, because some services on the bus can be used to run commands outside the sandbox, which is why narrow talk-name rules are preferable to blanket access.