Should warn or enforce when conflict between Flatseal permissions and user file choice

[BillDietrich]

User or admin sets filesystem restrictions for app A in Flatseal. There should be a warning in Flatseal saying: "user can override these restrictions in file-dialog at run-time".

At run-time, user in portal dialog for app A chooses a file that violates the filesystem restrictions for app A that were set in Flatseal. Dialog should give a warning at least, something like "you're violating restrictions set in Flatseal".

I understand the difference between app and portal. I think the UX is bad, and should be improved.

[ssokolow]

Manifest permissions (what Flatseal modifies) aren't intended to be the final verdict on things. They have no concept of "restrict"... only "undo default grant"... and they're intended to be compatibility crutches for applications which don't use the portals yet.

Flatpak operates on a default-deny paradigm, except for how the D-Bus proxy is hard-coded to grant permission to portal endpoints no matter what, and it's intended that average users need never manually manage per-application filesystem permissions because choosing something in the Open/Save dialog is implicitly granting permission.

Going tri-state with flatpak override settings and adding a "deny for portals" option would be to create an "I know you just asked me to do this, but are you sure you meant it?" option, because the file chooser portals are provided by a privileged process which runs outside the application container and, if the application has the power to subvert them, you've already got much bigger problems.

[BillDietrich]

I don't know the best fix, but what we have today borders on deceptive. User or admin thinks they're setting restrictions, but at run-time the user overrides the restrictions with no warning or failure. This is bad UX, and dangerous.

[ssokolow]

Then the correct thing to do would be to open an issue at https://github.com/tchx84/flatseal/issues asking for a message in the Flatseal UI that the permissions granted there only apply to filesystem access that does not go through the file chooser portals.

[smcv]

user can override these restrictions in file-dialog at run-time

User or admin thinks they're setting restrictions, but at run-time the user overrides the restrictions

It sounds as though you're misinterpreting Flatseal (and flatpak override) as setting restrictions that restrict/control/limit the user, and prevent the user from doing what they want to do (within the confines of what the overall system allows), to protect ... I don't actually know what you're aiming to protect here. Protecting a subset of the user's files from that user's own actions?

That is not what is intended. Flatpak's security model is that the user has full control over their own files, their own desktop session and so on, but the applications are generally not trusted (unless they have "powerful" permissions set). Flatseal and flatpak override are about setting restrictions that restrict/control/limit the application, to protect the user (or more precisely, to protect the rest of the user's interactions with the system, the rest of the user's files, and so on, from an application that might be malicious or compromised).

Flatpak is not intended to be a "parental controls" mechanism that will stop an untrusted user from doing things that Unix permissions would allow, and a user of Flatpak will typically have arbitrary code execution on a general-purpose computer (meaning they can run whatever code they want to run, even if that means writing it first).

If you want to protect "the system" from a user, Flatpak is not the right tool. Unix permissions/ACLs, or a LSM like AppArmor or SELinux, might be more appropriate.

[BillDietrich]

I filed https://github.com/tchx84/Flatseal/issues/196 a while ago; no joy.

[BillDietrich]

Flatseal and flatpak override are about setting restrictions that restrict/control/limit the application

This is a new and surprising security model, designed from a programmer's POV not a user's POV, where "app" and "app's dialogs" are somehow different. The user doesn't see it this way. The user will be tripped up by setting permissions in Flatseal and then not having them enforced in dialogs. I am not the only person to report this on reddit and elsewhere as "is something broken ? I set perms in Flatseal yet I can still access file X in the app". This is a bad UX, and it is going to cause grief for users and sysadmins.

[Mikenux]

The file chooser portal is to give the app only the selected files. Other file system permissions aren't just for restricting file access if the portal isn't supported in an app. For example, Firefox uses the file chooser portal but specified the xdg-download folder to automatically download files into it. Other apps have the file chooser portal but alsofilesystem=home to support recent files.

As smcv said, you need to use the appropriate admin tools to restrict file access.

However, why do you want to prevent users from accessing their own files depending on the apps if they are using the portal? The only thing I see to restrict file access is when apps don't use the file chooser portal or because of suspicious permissions (e.g. communication with other apps or processes, network access).

[Mikenux]

Isn't this issue the same as https://github.com/flatpak/flatpak/issues/3977?

[GeorgesStavracas]

After reading this discussion, it is unclear what's the goal or the proposal of this issue, and I couldn't withdraw any particular action from it. Closing it as it's not actionable. If you have specific suggestions on how to improve or modify the security model of Flatpak and portals, please open issues and discussions threads about them.