Once a file is opened with FileChooser, the permissions remain permanently in flatpak #1349
Comments
gentoo-root
changed the title
|
Hello @gentoo-root! This isn't new behavior. This allows to have a recent files list (where files are accessible) and to restore files. Regarding the privacy risk, an app can already keep an history of the files it accessed, no? Regarding the security risk, logically they can access files again without informing the user of that. The problem if we remove this is that we we'll need to ask to make them "permanently" accessible in case the user wants a functional recent file list (i.e. that opens the files) or wants session restore, which is common in apps. Here, why asking for something that is "commonly" expected? The other ways is to ask when writing files and when sharing files (network portal with relevant options), while it also depends on static permissions an app has. |
|
Hello Mikenux!
Not all applications have this concept of a built-in recents menu. Telegram Desktop, for example, doesn't have it: it opens the FileChooser every time, and the FileChooser can keep its own list of recent files. (Off-topic thoughts) For such functionality, I think it would be best if the portal had an interface for that. When the application attempts to open a recent file, it goes to the portal, and the portal grants the permission automatically based on its own list (or revoke the permission as soon as the file disappears from the recents). The list can be kept on the portal side. Anyways, given that many applications don't have the list of recents, and those that have it, only keep around 10 items:
I'm talking about a different sort of a privacy risk. Consider these cases:
Yes, that's what I find a problem. The file contents could have changed. The FileChooser UI gives an impression that I'm sharing the file with the application only once, but in fact the access remains permanent. One use case of Flatpak is to sandbox untrusted applications, but this behavior kind of puts extra trust on such applications, while confusing the user. |
That's not a problem of the Permission/FileChooser-portal but of the portal implementation. |
Are there implementations that revoke access after it's no longer needed? |
|
No, improving a UI that gives you misleading impression needs to be fixed by the protal implementations. |
|
Ah, sorry, I got you wrong.
From the user perspective, I don't think that's the right direction. Let's imagine it's obvious in the FileChooser dialog that the permission is given indefinitely. I believe, that would be even more confusing (at least it would confuse me): why does Telegram want to keep the access forever if I just want to send a file? how can I revoke the access? etc. |
|
BTW, does someone know how it works in snap? Does it also keep the access permanently, or does it have some revocation mechanism? I believe it uses the same portals and the same dialogs, but I don't know how the permissions are handled on snap level. |
|
In my opinion, informing about this in the file chooser UIs will clutter them unnecessarily. To remove this permanent access, we then need to know how to properly ask users for it when apps need it. If permanent access is kept, ask your DE for the ability to remove this file access permission. For example, for GNOME, this might be a feature to add in Settings > Privacy & Security.
Is this currently possible? If that's the case, isn't it up to system policy to deal with that?
Are file access actually kept in the permission store once deleted? If so, perhaps open a separate request for this (i.e. remove file access when the corresponding file is deleted)? (I'm not sure if this should be asked on xdg-desktop-portal or on flatpak, but issues can be moved between issue trackers) |
|
As a User and Developer I expect the Portal to give permanent access and would not treat it at a security risk. There are cases where a Program needs permanent access e.g. when selecting a save folder or when using a recent files feature. |
Yes. If I can run this command in the command line, a game could do the same. Games are usually not sandboxed. Even Lutris flatpak allows games to run
Maybe it is, but what exactly do you mean by "system policy"? Some distributions ship with AppArmor, there are also third-party software like Firejail (and probably tons of other programs that implement what could be called policies), but there is no standard place to configure that, and there are often bugs that allow to circumvent policies. Not collecting sensitive data in the first place is a good step towards privacy.
Yes, I mentioned it in the OP.
Of course there are (although I believe your cases could be implemented in a better way than giving a permanent access to the current and future directory contents; see some thoughts above). That doesn't mean we can ignore other valid common cases, when an application needs a single-time access. Isolating applications and giving them fine control over files is a security measure, and one of the concepts is the principle of least privilege. If the application only needs to read a file once, the portal should ideally give it this exact scope of permissions. No write access, no multiple open access, no permanent access to all future versions of the file, etc. If another application needs to read and write a file during the session (while it's open), then the portal should ideally give that other application this other scope of permissions. That is, Telegram would be able to request a single-time read access, while some text editor would be able to request a session-long read-write access, etc. What I'm saying is we don't need to break other use cases to reduce the attack surface in case of Telegram (threat model is Telegram becoming malicious or hacked and reading new versions of files at paths previously shared with it), both options can coexist, and while it may make sense for other applications to keep prolonged access, it's not needed for Telegram, but Telegram currently has no option to opt out. |
For unsanboxed games without using flatpak, then only the role of system policy (and yes I mean permissions, AppArmor, SELinux, ...). If the game is using flatpak, then maybe flatpak can block itself access to permission store even when using flatpak-spawn. You need to ask that on the flatpak repository.
That's then an improvement to have. For the rest, as said we at least need to know how to ask for recent files (or if an app want to show a list of more than 10 recent files), session restore, and possibly other cases I don't think of. We also need to know why keeping this access was done in the first place. |
If an untrusted program can execute arbitrary code with your privileges, then that's game over for any sort of security boundary, because anything you can do, it can do - including for example reconfiguring your session bus so that it will start its own modified version of xdg-desktop-portal that has different behaviour. There is no change that could be made in xdg-desktop-portal that could possibly prevent this. Sorry, this is just not a threat model that is solvable. If you want a subset of your apps to be treated as less-trusted (potentially malicious or compromised), then the first thing that is needed is to put up a security boundary between those apps and the trusted computing base (your desktop environment). Possible implementations of that security boundary include Flatpak (with suitably restrictive sandboxing parameters), Snap (ditto), and fast-user-switching to a separate uid that runs its own desktop session and cannot access your sensitive personal files.
If that's the case, then you cannot run untrusted software from the Lutris Flatpak app and expect to be protected from it. Flatpak apps that allow |
|
This is not an problem that can be easy solved. Programs are developed with the fact, that they have permanent access to a file, in mind (the file could of course be deleted). If we change this, we break programs.
That won't work. Most programs don't call the Portal directly. They just just the FileChooser Function of their Toolkit and the Toolkit calls the Portal. So we can't really add Options to the FileChooser Portal. |
If it has to change, maybe we can have a mechanism to know which apps are using the old way (permanent access by default) vs. the new way (no permanent access by default).
I have open issues about that: read-only by default, ask to write. However, I need to rewrite to better organize that.
Most programs don't call the portal directly - yes, but the toolkits can implement new functions if they are implemented in the portal. Just that if there are new functions, current programs shouldn't break the time developers are updating. Currently, I see only one thing that can be possibly done: Autoremove file access permission when corresponding files are deleted. But doesn't it a flatpak issue? To continue on about removing permanent access to files, as already said, we need to know why this permanent access exists in the first place. @smcv? |
Operating System
Arch Linux
XDG Desktop Portal version
1.18
XDG Desktop Portal version (Other)
1.18.2
Desktop Environment
GNOME
Desktop Environment (Other)
No response
Expected Behavior
The documents entries should be removed from
flatpak permission-show ...at some point, for example, on application restart, or (better) when the application is done working with the file.Current Behavior
Once a file is opened with FileChooser in a flatpak application, that application gets permanent permissions to access that file. This poses a security risk (the application can access the file when the user doesn't expect it) and a privacy risk (it's possible to dump a full history of all opened file names, even when those files no longer exist; clearing this "history" isn't obvious).
Steps to Reproduce
flatpak permission-show -v org.telegram.desktopAnything else we should know?
I saw #689 and flatpak/flatpak#4303, but those seem to refer to the FDs not being released, while I'm reporting flatpak permissions not being removed.
The text was updated successfully, but these errors were encountered: