One of the main issues I have with Flatpak are (IMHO) lenient default settings. Have used FP for a few years, and only now discovered it also allows for rw access to number of xdg directories by default.
This led me to add following to ~/.local/share/flatpak/overrides/global:
$ cat global
[Context]
sockets=!gpg-agent;!pcsc;!ssh-auth;!system-bus;!session-bus
filesystems=!~/.gnupg;!~/.ssh;!xdg-documents;!xdg-config/systemd;!home;!host
[Session Bus Policy]
org.freedesktop.Flatpak=none
org.freedesktop.secrets=none
Is this reasonable approach? Curious from others in the community which global hardening rules y’all have set up.
Can’t speak for the whole backcatalog, but for new submissions unrestricted access to folders requires a good reason. Permissions should already be quite strict in many cases.
By default flatpak gives access to nothing except private directory under ~/.var/app. All permissions you may see are added by app developers and you have right to override them as you wish.
Sorry guys, thought I had posted this on Fedora forums and was surprised nobody was replying
My wording in the OP was poor. What I meant was: originally my filesystems global override had only !home, assuming that everything under it would be disallowed; only to discover flatpak has special xdg-* rules that allow individual apps to get access to those directories even with my !home rule present.
Not knowing all the permutations, it seems counterintuitive to me that ~/Documents (i.e. xdg-documents) could be accessed with a global !home override – this in particular caught me off guard.
Again, my poor wording, soz. See above.
It’s a file I manually created to further harden the flatpak installations.
The default – please correct me if I’m wrong – is the individual apps can ask access to wherever. My global override intention is to disable that behavior, so I can explicitly allow specific apps access to whatever they need. E.g. no app should ever access the entirety of xdg-config, imho (although, given how bwrap works, it also cannot give access to just xdg-config/app if that /app node does not already exist). At least I have plenty of sensitive stuff in there.
And to re-iterate, with !home rule in place, I would expect the individual app xdg-* access rules not to override it.
The default – please correct me if I’m wrong – is the individual apps can ask access to wherever
You are wrong. At the time of my comment i checked and entered a sandbox, and couldnt access anything. Default setup. No access to anything, only the apps own datadir
The filechooser shows you everything, but not because the app sees it, but because the app uses portals, and will be granted access to whatever you select explicitly
Aside from that i have no clue where you pulled your explanation from, but if it were true us reviewers wouldnt get death by a thousand cuts of people asking for said full access as static permissions, and there would be no point to the format itself
Let’s take libreoffice with its --filesystem=xdg-config/gtk-3.0 rule. This means I can run flatpak run org.libreoffice.libreoffice ~/.config/gtk-3.0/myfile.xlsx and it will open it, although there is a !home override in place. (note providing file on CLI bypasses portals, so it’s not it)
My issue with this is that user needs to know all the rules and their permutations. Intuitively I feel that !home should mean “everything in home is disallowed”, and individual apps shouldn’t be able to carve exceptions into its subdirectories.
I told you override doesn’t work like that already, what’s your point here?
If it worked like you said then !home would result not only with no filesystem access but also with broken theming and fonts. Most users would be fine without home but there may be several subtle paths needed for some basic functionality and it’s above average user understanding how to restore them if !home overrides them all. At same time they’re marginal for security (BTW: probably LO should have read-only --filesystem=xdg-config/gtk-3.0:ro) access.
If you want to be in charge of all permissions then use --sandbox option which cancels them all, not only filesystem.
Your answer explained it well. My last post was more to exemplify my case for u/teamcons.
Out of curiosity, why would it break the entire filesystem access? Because !host rule would block access to everything whatsoever? Which is a valid point.
I’ll read up on it, wasn’t aware there’s an actual sandbox opt. But think I’ll continue on current path, but have to be more careful about denying the existing rules.
Yes, but that’s debatable. If a program asks permission to the entire xdg-data or xdg-config, then that often contains sensitive data. E.g. default atuin db is in the former, default copyq db is in the latter. Secrets may easily leak into either.
Should these issues be raised with upstream problems, or is the flathub/project okay venue?
Just realized this is not true in terms of flatpak, as filesystems nodes support :create suffix. Would it be reasonable to raise issues with specific projects that require e.g. rw to xdg-config as opposed to xdg-config/app:create?
yes, if something has access to entire xdg-config only to use app specific subdir then it’s clear bug and should be reported to that app repo. I’m pretty sure flathub wouldn’t allow such thing nowadays.
I don’t see any fs permission in copyq. I can’t find atuin on flathub at all. Where do you see that?
Atuin and/or copyq could be installed natively (which is the case for me), and whatever fp-installed program asking access to the entirety of xdg-* can pull my CC numbers that got accidentally copied to the clipboard or AWS token I used in a shell command.
