Please improve UI to emphasize that portals override permissions

[BillDietrich]

As a new user of Flatpak, I was shocked to find that permissions I set (via CLI or Flatseal) are overridden by portals. For example, the file-chooser dialog lets a user save a file anywhere, even though in Flatseal I have turned off all filesystem permissions and allowed only a couple of specific directories. To me, it looked like Flatseal simply was not working; permissions were not enforced.

Now I understand that this is deliberate design by Flatpak. I disagree with that design. Nevertheless, I think Flatseal should be much clearer that many of the restrictions it sets can be overridden by user action in the app's GUI. The current UI is misleading IMO.

I'm using Flatpak 1.6.5 and Flatseal 1.6.3 on Ubuntu MATE 20.04.

Thanks.

[tchx84]

hey @BillDietrich

This is something that could be improved in multiple ways (at once):

1. Mention this in our documentation.
2. Think of ways of conveying this information in the UI. I am not a fan of explicit warnings in the UI for things that are beyond Flatseal control, but I am sure there's a way.
3. Support portals.

re. (1), Can you send a pull request adding that comment to Flatseal's docs?

re. (2) I will tag this issue for design feedback.

re. (3) I am currently exploring this, and so far with promising results (see #190). This means you will be able to revisit/manage your decisions/permissions made through portals. Here is where we could include some hint about this behavior, e.g. in the Portals group description, include something like "These take precedence over any other permissions" or something.

[Arxcis]

@BillDietrich Would you like to keep portal-permissions in a separate portals-section, once they are included in Flatseal, instead of mixing into the existing filesystem- or device-section?

I can see benefits of both.

If keeping portals-permissions in a separate portals-section, we can clearly mark the entire section with a message like: "The portal-permissions override permissions in the filesystem- and device- section"

On the contrary, mixing the file-related portal-permissions into the filesytem-section, you get the benefit of having all filesystem-related permissions in the same section. If you then turn off everything in the filesystem-section, you will be sure the app has no filesystem access - you dont have to check the portals-section as well.

🤔

I am sensing that one of these alternatives is a good default, but some users would prefer the other alternative.

Maybe @tchx84, is it possible to do both? Mix filesystem-related portal-permissions into the filesystem-section AND also keep the separate portals-section?

[BillDietrich]

Sorry, I don't think I can contribute much here. What are "portal permissions" ? Are they per-app, or per "portal" (e.g. all file-open dialogs in the system will get permissions X) ?

I'm still a bit in shock by finding that portals override container permissions, both for Flatpak and now I hear Snap will be using them too. This seems to make container permissions totally worthless, to me. I want per-app permissions that the user has a nice GUI to control.

[Arxcis]

Flatpak's philosophy here is to give back control to the user. If you turn off all the default permissions of an app, it means that the app has to ask the user for permission, every time it needs access to a resource.

To ask the user for permission to access a given resource, a Flatpak app is expected to use one of the well-known DBus-interfaces defined as a xdg-desktop-portal, documented here ->
https://flatpak.github.io/xdg-desktop-portal/portal-docs.html
https://github.com/flatpak/xdg-desktop-portal.

If you turned off all file-permissions for an app, the app cannot just start reading files directly from disk anymore. It has to ask the user by talking to the org.freedesktop.portal.FileChooser.

When the app invokes a request to the FileChooser-portal, the user is presented with a file-chooser GUI by your desktop environment (Gnome, KDE). This file-chooser is completely out of control of the app. When a user selects a file in the file-chooser, the app, and that app only, is given permission to the exact file the user selected, and no other files.

The specific permission, for an app to be able to acces the specific file the user has selected, is what we refer to as a portal-permission. This permission is stored in a dynamic permissions storage, per app.

Flatseal is not able to display these permissions currently, but #190 will address this.

[BillDietrich]

When a user selects a file in the file-chooser, the app, and that app only, is given permission to the exact file the user selected and no other files. This specific permission is what we refer to as a portal-permission.

Ah, okay, you're referring to this implicit "user gave permission by clicking Open button" thing.

Sorry, I think this whole design is disastrous and misguided. I want to be able to set a policy "Flatpak app A can access only directories A, B, C" and nothing the user does at run-time overrides that. And I want to be able to set different policies for different apps. I don't care if the access an app tries to do is stimulated by something "inside" the app, such as a timer or extension or whatever, or by a user click "outside" the app in a GUI dialog.

If the policy is wrong, the user should have to do something very special (Flatseal) to change the policy, not just click normal "Open" button to completely override the policy.

It's similar with file mode settings and cp today. I set a policy with chmod. If user tries a cp that violates the policy, system doesn't just say "well, user deliberately typed cp, he/she must REALLY mean it, so override file mode settings". User has to change the policy (chmod) or do something else special (sudo) to override the policy.

And re-using a standard UI ("Open" button in file-chooser dialog) to mean something new ("override security policy") is just wrong.

This whole portals thing seems a train wreck, to me. Destroys any point of setting permissions on containers. Worse, silently overrides those policies, giving a false sense of security to the user/sysadmin who sets the policies.

[Arxcis]

This whole portals thing seems a train wreck, to me. Destroys any point of setting permissions on containers. Worse, silently overrides those policies, giving a false sense of security to the user/sysadmin who sets the policies.

I think what you are asking for, is an interesting use-case, but as far as I know your use case is not within the intended scope of Flatpak. I would recommend looking for other solutions than Flatpak to solve your problem.

[BillDietrich]

as far as I know your use case is not within the intended scope of Flatpak

Interesting. So, exactly what is the point of the permissions that Flatseal can set on a Flatpak image ?

[Arxcis]

Interesting. So, exactly what is the point of the permissions that Flatseal can set on a Flatpak image ?

The main problem Flatpak is trying to solve, is to make it easy for developers to deliver an app to users across linux distributions.

As a developer, instead of making a debian package for Ubuntu, and a rpm package for Fedora, and a pacman package for Arch/Manjaro, you make a single Flatpak-package, which runs on all of these platforms.

A Flatpak has an additional benefit of running in a sanboxed environment. This makes it necessary for an app to list all the permissions it requires from the host to function properly. Flatpak is not a security-by-default design, and allows apps to ask for any permissions upfront.

By installing an app, the user accepts to give the app the permissions it is asking for.

In Flatseal, you are able to override these default permissions.

NOTE: They are not run-time permissions, which is why you have to restart the app for the permissions to take effect.

Disclaimer: I am not a Flatpak expert.

[tchx84]

as far as I know your use case is not within the intended scope of Flatpak

Interesting. So, exactly what is the point of the permissions that Flatseal can set on a Flatpak image ?

Flatpak supports two types of permissions models:

Static: these are permissions that app developers define when they package the app with flatpak. e.g. --filesystem=home. These permissions can later be changed by the user with overrides, by using flatpak-override CLI tool or Flatseal. The reason static permission exists is because is a much simpler model for app developers to adopt and to transition their apps to Flatpak. In other words, the benefit of static permissions is that it doesn't require the developer to change anything in their app's code. The "downside" is that creates this initial "all-or-nothing" situation where the user has to "be ok" with these initial set of permissions when they install the app.

Dynamic: these permissions are requested to the user during runtime, e.g. you run the app and a popup shows asking you for explicit permission to use geolocation service. These permissions can later be changed by using flatpak-permission CLI tool (and soon Flatseal, as well). Dynamic permissions are also referred as "portals". The benefit of this model, over static, is that it gives much fine grained control to the user to decide which specific permissions to grant, vs the initial "all-or-nothing" approach of static permissions. The "downside" of dynamic permissions is that requires app developers to implement these in their app's code.

So, summarizing, there are good reasons for having boths permissions models. Because they serve different purposes, given that the Linux app ecosystem is wild. But from my POV, flatpak is being smart by allowing these transitional steps.

[BillDietrich]

A Flatpak has an additional benefit of running in a sanboxed environment. This makes it necessary for an app to list all the permissions it requires from the hots to function properly. Flatpak is not a security-by-default design, and allows apps to ask for any permissions upfront.

Portals violate everything you just said in this paragraph.

I understand what Flatpaks are for; I don't understand what the up-front permission model is for, if it can be casually and silently violated by the user at runtime.

[BillDietrich]

you run the app and a popup shows asking you for explicit permission to use geolocation service

So maybe my problem is that some portals (geolocation) have a dialog that explicitly says "you're giving a new permission to the app", and other portals (file chooser) don't. File-chooser is just using same old UI, but now it can mean "override permission setting".

[Arxcis]

It's similar with file mode settings and cp today. I set a policy with chmod. If user tries a cp that violates the policy, system doesn't just say "well, user deliberately typed cp, he/she must REALLY mean it, so override file mode settings". User has to change the policy (chmod) or do something else special (sudo) to override the policy.

Keep in mind: A Flatpak app runs as an unprivileged user-process, and still requires sudo to do sudo-things. In other words, you can still set per-user policies with chmod, and the Flatpak apps cannot override this.

[BillDietrich]

A Flatpak app runs as an unprivileged user-process, and still requires sudo to do sudo-things.

The chmod/cp thing was just an example. Why have Flatseal at ALL, if at run-time the user can casually/accidentally override anything set in Flatseal ?

[Arxcis]

Because Flatpak is a user-tool, not a sysadmin tool.

[BillDietrich]

Because Flatpak is a user-tool, not a sysadmin tool.

I think that's irrelevant. Flatseal lets someone (call them user or sysadmin) set permissions. Then the app/user casually or accidentally overrides those permissions at run-time. So Flatseal/permissions are useless, or even worse giving a false sense of security.

[BillDietrich]

Question: if user A uses Flatseal to set permissions on Flatpak image I, is it setting (initial) permissions for all users of that image I ? Or just for user A ?

How does a sysadmin set (initial) permissions on image I so all users get those (initial) permissions ?

[tchx84]

Question: if user A uses Flatseal to set permissions on Flatpak image I, is it setting (initial) permissions for all users of that image I ? Or just for user A ?

How does a sysadmin set (initial) permissions on image I so all users get those (initial) permissions ?

Apologies, but I believe we have given you enough information to respond to your doubts. I would recommend to do more research on what Flatpak is and what it tries to solve, on your own.

The most I can help you with now, is to second @Arxcis comment that you seem to be looking at Flatpak to solve a problem that Flatpak is not trying to solve, as I already explained above why both permissions models exists.

[BillDietrich]

I believe we have given you enough information to respond to your doubts

Okay, I'm sure you're sick of talking to me. Let me try to sum up:

I think portals / Flatpak / Flatseal have a number of functionality and UI issues. You risk a disaster (insecure systems, unhappy users, etc) if you don't fix them:

• Functionality:

1- There should be a way to prevent portals at run-time from overriding permissions set on images by Flatseal or the image's dev.

2- There should be some group-policy thing (if there isn't already) where Flatseal can set permissions so all users in the system inherit same permissions for that image.

• UI:

3- (Unless item 1 is fixed:) Portals should have UIs that make it clear what is happening. If in a file-chooser dialog, a user goes outside the bounds of permissions set by Flatseal, that should be very clear in the dialog's UI.

4- (Unless item 1 is fixed:) Flatseal's UI should have big warnings somewhere that permissions can be overridden by portals.

5- (Unless item 2 is fixed:) Flatseal's UI should have big warnings somewhere that permissions apply only to current user.

Thanks for your time.

[Arxcis]

How does a sysadmin set (initial) permissions on image, so all users get those (initial) permissions ?

One suggestion

The sysadmin could create his own Flatpak, with his own preferred initial permissions, and ask (or force) users to install his Flatpak instead of the official one. It could be a fork of an existing Flatpak, where the sysadmin adds his own preferences on top.

A great example of taking an existing Flatpak, and harden it, is the "Ungoogled Chromium"-flatpak -> https://github.com/flathub/com.github.Eloston.UngoogledChromium/blob/beta/com.github.Eloston.UngoogledChromium.yaml

Here unnecessary static permission like --filesystem=home, has been removed.

"Ungoogled chromium" also applies a bunch of patches to the source code, to further harden/customize things --> https://github.com/flathub/com.github.Eloston.UngoogledChromium/blob/beta/com.github.Eloston.UngoogledChromium.yaml#L231-L252

Needless to say, there is nothing stopping the user from un-patching these patches, so if you are looking for guarantees like that, Flatpak won't help you.

[Arxcis]

@BillDietrich Actually Flatpak allows you to install apps system-wide, with the --system flag. (requires sudo) That could be worth looking into. I have not used that feature much myself.

Also here is a writeup from the creator of Flatpak, Alex Larsson, about the security model https://blogs.gnome.org/alexl/2017/01/24/the-flatpak-security-model-part-3-the-long-game/ , relevant to this disussion. Part 1 and part 2 is also useful.

[tchx84]

Thanks for your time.

Thanks for your feedback, ill certainly take your UI comments into account for #190.

[tchx84]

So, I landed portals permissions a few days ago, but I haven't iterated over the descriptions yet. If someone here wants to help with this, you're more than welcome.

[Arxcis]

Well done @tchx84. Appreciate all the work you have put into on this feature 🙏