Flatpak: "home" access allows trivial privilege escalation, what to do instead

This Github issue describes the problem well

If an app has the static filesystem permission for home, it can place this override file to give itself any possible permission.

mkdir ~/.local/share/flatpak/overrides
cat >> ~/.local/share/flatpak/overrides/my.awesome.App <<EOF

This concept is actually how Flatseal works, placing override files for each app and thus modifying their permissions.

If this was only possible for reducing the permissions, it would be harmless and even useful. But it is a direct way for privilege escalation instead.

The issue was closed, which I find concerning. The general tone is

If an app has home permission, dont expect it to be secure.

I think this is pretty bad and there are 2 ways to tackle this.

1. Block access to all dotfiles.

Apps that have home permission can no longer read and write

  • your ~/.bashrc
  • your ssh and gpg keys
  • these permission overrides
  • …

and much more. Flatpaks have no business in the dotfiles, even though Cryptomator devs think it should.

And even if apps need that, they can specify the exact directories. This is how Flatsweep does it, while Flatpak normally blocks access to ~/.var/app (to allow “containerization”, while all apps with home permission could just change their permissions, lol)


But this needs to be done at a Flatpak level, see this issue.

2. Override for all apps with home permission

I really like @pkmays’ approach to this

They used a general override for all apps, resulting in a permission page like this:

KDE Plasma systemsettings permission page

This works really well, but as a side effect (I think) breaks all preset permissions by apps. There are very few apps like Gnumeric that have too little permissions, but most have just the permissions they need.

So this would sometimes lead to extended privileges and lots of manual work (it is not a scaleable concept).

What would be a good way to do a function, all apps with home permission get such an override file placed? Best would be in a non user-writable directory.

Are there differences in --user and system installed apps?


Having a variant of the home permission that excluded hidden files would be nice to have, but only if it could be implemented cleanly, and that doesn’t seem to be the case. Neither of the options mentioned in flatpak/flatpak#4632 (comment) are really viable. Moreover, even if sandbox escape would be more difficult without dotfile access, it’s still fundamentally insecure. Consider a ransomware attack encrypting all your files for example.

As a user, you could play whac-a-mole with all the directories you can think of, but I’m not sure it’s worth the pain given the limited benefit.

Improving portals and portal adoption is the only real way out. Until then, I’m pretty cautious about running apps with home (or greater) access and will take it away if it’s not really necessary (e.g. Evince).


i discover today that gnome-boxes dont respect the flatseal when i turn off internet on it, it still continuous to access internet.

I though these permissions on flatseal would enforce the flatpak, but i discover that is not true

1 Like

That does seem to work, but Boxes likes to run in the background, so you need to terminate it or restart your session after removing the permission. See flatpak ps and flatpak kill.


Insteresting, i didnt allow in gnome settings the permission to it run in background and even denied it didnt respect, gonna try this command, thanks

you were right , i open it, close it and it still shows, running flatpak ps, but it dont show in gnome system “running in background”. I have other flatpaks that shows in “gnome background apps” after closing it but not boxes

1 Like

Yes that is true.

But as mentioned, “we just need to implement portals everywhere” is not an argument to lay back and do nothing for like 5 years until that is done.

I maintain a list of modern flatpak apps.

This and the security rating on Flathub and GNOME Software (not yet in KDE, COSMIC and not sure about other DEs) are the only way to have some kind of security.

And still, there seems to be a way for ~/.var/app so I dont think it is impossible?

The other way around, “sandboxed” flatpak apps give a false sense of security.


A different idea (as a harm reduction workaround) could be to block many privileged locations and files, to only allow root to write them.

This could for sure be done better with selinux-confined-users

sudo chown root:root ~/.bashrc ~/.bash_profile ~/.zshrc ~/.config/fish ~/.local/share/flatpaks/overrides

Doing that for ~/.gnupg and ~/.ssh would break things like git which causes problems and would require running more processes as root, which is not wanted at all.

That doesn’t work because you (or a malicious app) can delete a root-owned file in a directory you own and recreate it.