I install a lot of my apps as Flatpaks on Fedora KDE, and I have never changed a single one of their Flatpak permissions. Not one toggle. I saw the word “sandboxed” and assumed somebody had already locked the doors.
That assumption is wrong often enough to deserve a post. The Flatpak sandbox starts out strict, but every app ships with a list of exceptions it asked for, and a few of those exceptions make the sandbox mostly decorative. Flatseal, and the permissions page built into KDE Plasma, let you take some of them back.
Sandboxed Doesn’t Mean Locked
Out of the box, a Flatpak app gets very little. Flatpak’s own documentation lists the defaults: no network, no access to your files beyond the app’s private folder, no devices, and a filtered line to D-Bus, the messaging system desktop apps use to talk to each other and to the system.
Then the app’s packager adds permissions on top, in the app’s manifest. You get them all at install time, without a prompt.
Flathub shows those permissions on each app’s page and labels the risky ones “potentially unsafe.” So many popular apps carry that label that most people stop reading it. Even Flatseal’s own Flathub page has it, which makes sense: editing other apps’ permissions is exactly the kind of power the label warns about.
The label isn’t the problem. Nobody going back afterwards to trim what each app was given is.
Flatseal and KDE’s Permissions Page Flip the Same Switches
Flatseal
Flatseal is a small app by Martin Abente Lahaye, currently at version 2.4.1 on Flathub. It works on any desktop:
flatpak install flathub com.github.tchx84.FlatsealPick an app on the left and its permissions appear on the right, grouped by type. Per the project’s README, you restart the app after a change, and a Reset button puts everything back.
KDE’s Application Permissions page
If you’re on KDE Plasma, you already have this built in. Plasma 6.5 turned the old Flatpak Permissions page into a general Application Permissions page, under System Settings, Security & Privacy. It covers the same sandbox switches, plus things you approved through a portal, the system pop-up that asks before an app takes a screenshot or accepts remote control.
That second part makes it the better pick on KDE. Plasma is the desktop I keep recommending, and this is one more place where Plasma puts the control in System Settings instead of in a separate app.
If the page shows nothing for your Flatpaks, your distro ships it as a separate package, usually called flatpak-kcm (kde-config-flatpak on Debian and Ubuntu).
Both tools write Flatpak overrides: small settings files that sit on top of what the app asked for. The app itself isn’t modified, so an update doesn’t wipe your changes.
Flatpak Permissions Worth Locking Down
These are ordered by how much damage the permission can do. The labels are Flatseal’s; KDE’s page uses similar wording.
| Permission | What it really allows | What to do |
|---|---|---|
Session Bus, Talks: org.freedesktop.Flatpak | Running any command on your system, outside the sandbox | Remove unless the app’s job needs it |
| D-Bus session bus / D-Bus system bus | Unfiltered access to every service on the bus | Switch off |
| All user files / All system files | Your whole home folder, or more | Replace with specific folders |
| X11 windowing system | Seeing other X11 apps’ windows and keystrokes | Switch off if the app supports Wayland |
| All devices | Webcams, USB devices, everything in /dev | GPU acceleration is usually enough |
| Network | The internet | Switch off for apps that work offline |
The one that cancels the rest
A talk permission for org.freedesktop.Flatpak is the master key. Flatpak’s own security advisory describes that service as deliberately giving flagged apps the ability to run arbitrary code on the host.
Code editors and developer tools use it to reach compilers installed on your system. A music player or a note-taking app has no reason to hold it.
Full bus access
D-Bus filtering is what keeps an app talking only to the services it listed. The Flatpak documentation says full session or system bus access switches that filtering off, calls it a security risk, and says it should be avoided unless the app is a development tool.
Home and host access
“All user files” sounds like a convenience. It means the app can read your SSH keys and other apps’ data, and it can write files like ~/.bashrc or ~/.config/autostart, which run outside the sandbox the next time you open a terminal or log in.
Switch it off, then add only the folders the app actually uses under “Other files.” xdg-download gives it your Downloads folder, and adding :ro to a path, as in ~/Music:ro, makes it read-only.
Apps that use the system file picker will still open any file you choose, because the picker grants access one file at a time. Apps that don’t will suddenly show empty folders. That’s your cue to add one folder back, not to restore your whole home.
X11 on a Wayland desktop
Plasma 6.8 and GNOME 50 no longer ship an X11 session, so X11 apps run through XWayland, a compatibility layer. An app holding the X11 permission can still watch what happens in other X11 apps, though not in your native Wayland ones.
If an app lists Wayland as well, switch X11 off and relaunch. If the window doesn’t appear, turn it back on.
Devices and network
“All devices” includes your webcam and anything plugged into USB. Most apps only need “GPU acceleration” for smooth graphics.
Network is the easy win for apps that work on local files, like a PDF reader or an image viewer. If an offline app wants the internet, ask why.
Pro Tip: Before removing bus permissions, run
flatpak run --log-session-busfollowed by the app’s ID, then use the app normally for a few minutes. The log shows which services it actually talks to, so you remove the unused ones instead of guessing.
How to Undo a Change That Broke Something
Change one permission at a time, the same rule I gave for Firefox about:config. When something breaks, you’ll know which switch did it.
- Restart the app. Changes apply on the next launch, so a running app won’t reflect them yet.
- Press Reset in Flatseal. It clears your overrides for that app.
- Use the terminal if a tool won’t open. The flatpak override command shows and clears overrides for one app:
flatpak override --user --show com.example.App
flatpak override --user --reset com.example.AppIf the overrides were set system-wide, run the reset with sudo and without --user. Swap com.example.App for the real ID, which flatpak list --app prints.
Stay away from Flatseal’s “All Applications” entry until you know what you’re doing. A change there applies to every Flatpak at once, and one bad global override can break a dozen apps on their next launch.
Start with the Apps That Have Everything
You don’t need to audit every app. Open your permissions tool, look for the apps holding home access and network together, and start there. That combination is the one that can both read your files and send them somewhere.
Ten minutes per app closes most of what the packager left open. The sandbox is good. It just needs you to finish the job.
Frequently Asked Questions
Is Flatseal safe to install?
Flathub marks it “potentially unsafe” because it can change other apps’ permissions, which is its whole purpose. It edits Flatpak overrides and nothing else.
Should I use Flatseal or KDE’s Application Permissions page?
On KDE Plasma, the built-in page, since it also covers portal permissions like screenshots and remote control. Everywhere else, Flatseal.
Do my changes survive app updates?
Yes. Overrides are stored separately from the app, so updates don’t reset them. An update can still add new permissions, so check apps again after big version jumps.
Will removing home access break my app?
Sometimes. Apps that use the system file picker keep working. Apps that read files directly will need the specific folders they use added back.
