[Feature request]: Permission whitelist

[robertvazan]

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Suggestion

Apps like to grant themselves rarely used permissions "just in case" and expand them upon update or reinstall. Arguing with app developers is not going to work, because supporting the last 1% of use cases is always more important than sandboxing. I am usually not in that last 1%, so I end up with apps asking for lots of permissions I would never use.

I would like to have more control over permissions. I am currently playing whack-a-mole with overrides. I have a laundry list of permission overrides in a script, which is laborious, unreliable, and fails over time as new types of permissions are introduced in Flatpak. There's --nofilesystem=host:reset, but I need something similar for other permissions. There's also --sandbox, but it can be only used with flatpak run and not flatpak override. I can have my script modify the manifest and rebuild, but that's a lot of complexity I would like to avoid (YAML, JSON, build sandbox). Ditto for parsing flatpak info --show-metadata. Ideally, I would like the app to have permissions that are an intersection between app manifest and my whitelist. As a second best option, I would like the app to have exactly those permissions that are in my whitelist. In any case, the app should have no way to obtain permissions outside the whitelist.

As for how to expose this to the user, I am thinking of --sandbox on flatpak override that would drop all permissions from the manifest. The parameter could optionally take a value that would clarify the nature of the sandbox, for example whether to drop also generally safe permissions (Wayland) and default permissions (session bus). Another possibility is to give --reset an optional value that could be used to request drop of permissions from the manifest.

Edit: clarified this is for use in scripts, mentioned --show-metadata

[chrisawi]

This is similar to #3917

[nanonyme]

While the idea seems nice at first, consider that these same app maintainers who previously refused to remove permissions have privilege to trash any future bug reports you file that might happen because of this whitelisting. Your configuration will be unsupported and if you want to fix anything, you end up forking the app. And if you forked the bad apps in the first place, you could set the permissions and wouldn't need this feature.
Most apps I use in fact have quite limited permissions and if you touch them, the apps break.

[robertvazan]

@nanonyme I already have some experience with this and my observation is that apps basically never break when I restrict their filesystem access to a subfolder of the home directory. They don't break when I disable network access, child sandbox spawning, or device access even if some non-essential feature depends on that functionality. I know that with custom setup, my bug reports might be rejected. I can repro in a full-blown VM in those rare cases.

[nanonyme]

I assume you mean Steam by child sandbox spawning. It might be useful to know it is most likely going to be mandatory by upstream (Valve) over time.

[robertvazan]

@nanonyme Not Steam. I remember some other app needing it to launch external editor or something.

[rusty-snake]

There is no child sandbox spawning permission. Every flatpak can spawn child sandboxes. org.freedesktop.portal.Flatpak permission is about running commands unsandboxed (=on the host) via flatpak-spawn --host.

[robertvazan]

@rusty-snake Thanks for clarification. That's indeed what I had in mind - escaping sandbox by running external commands. It's used by some apps to support non-essential features.