Sandboxing stopped: Flathub apps have access to all folders and files outside their sandbox. What could cause this challenge?

1

Hello Flatpak enthusiasts,

One question down below. We are facing an unusual challenge, on one device, sandboxing fully stopped. The challenge is that all installed Flathub Flatpak sandboxed applications have access to all folders and files outside their sandbox. The needed end result is that those apps should not have access to any folder or file outside their sandbox. Per both the Flatpak global and per Flatpak app configuration.

For the past years, that sandboxing was very successful on that same device. No challenge. Then, for the last few days, all the same sandboxed applications have access to all folders and files outside their sandboxes.

Question: Beside what we already tried, which is listed down below, what could potentially be causing this challenge above?

-– — — — — — — — — — — — — — — —

Below is the same message as above. But with details if you’re interested in those.

-– — — — — — — — — — — — — — — —

Using

• Flatpak: 1.14.10

• Debian: 12 Bookworm

• Type: x86_64

• Display: Wayland

-– — — — — — — — — — — — — — — —

Steps to reproduce

1. Install Flatpak 1.14.10

2. Using Flathub, install apps

3. Sandboxing is successful for months. Sandboxes apps do not have access to any folder or file outside their sandbox. Joy. So no challenge yet.

4. One day, on the same device all the same sandboxed applications have access to all folders and files. Regardless of Flatpak app’s global configuration or per app configuration. Those app should not have access to any file or folder outside their sandbox. That we know of we have not changed anything to the configurations on that device.

5. This challenge can always be reproduced. For all Flatpak apps. But only with the same device. We are not able to reproduce this challenge on any other devices.

6. The needed end result is that, on that device, Flatpak sandboxed apps should not have access to any folders and files outside their sandboxes. Per both the Flatpak global and per app configuration.

By “access to all folders and all files”, I mean this, for exemple:

___ 1. Install this Kwriter Flatpak app from https://flathub.org/en/apps/org.kde.kwrite

___ 2. Using Flatseal from https://flathub.org/en/apps/com.github.tchx84.Flatseal configure the sandboxe access permissions like this:

______ Global:

_________ “Filesystem” group:

____________“filesystem=host” DENIED

____________“filesystem=host-os” DENIED

____________“filesystem=host-etc” DENIED

____________“filesystem=home” DENIED

__________ Kwriter (org.kde.kwrite) app:

____________“Filesystem” group:

_______________“filesystem=host” DENIED

_______________“filesystem=host-os” DENIED

_______________“filesystem=host-etc” DENIED

_______________“filesystem=home” DENIED

____________ “Other file” group:

_______________/home//Documents/

___ 3. Reboot device

___ 4. Using Kwriter try to read or writer a file stored in any folder OUTSIDE Kwriter sandbox. Kwriter has both read and write access to those files and folders. This is the challenge. Why? Because that folder is outside the sandbox:

______ /home//Downloads/test.txt

______ /home//media///test.txt

___ 5. Using Kwriter try to read or writer a file stored in the only folder INSIDE Kwriter sandbox at

______ /home//Documents/test.text

______ Kwriter has access to both reading and writing to this folder above. Which is a success because this folder is inside its sandbox. In other words, the app is ALLOW read and write access to “filesystem=home”. This is the challenge.

___ 6. This challenge above can be reproduce with all Flatpak apps. Not just Kwriter.

-– — — — — — — — — — — — — — — —

What we tried that did not resolved this challenge

• Restarted device

• Double-checked permissions for ALL apps (global). Using:

•___ Flatseal

• Double-checked permissions PER app. Using:

__• Command: flatpak info --show-permissions <APP.NAME>
__• Flatseal

• Installed new Flatpak app. Which was never installed before. Denied its access to any file or folder. That app also has access to all files and folders.

• This challenge can always be reproduced. For all Flatpak apps. But only with one and same device. We are not able to reproduce this challenge on any other devices. Still on that device, sandboxing was successful. But then, somehow stopped. Beside what we already tried, which his listed down below, what could potentially be causing this challenge?

• Searched tickets at [https://github.com/flatpak/flatpak/issues\\\] and Found no result.

• Created a ticket with Flatpak engine. A maintainer replied. The maintainer claimed to not understand that ticket. Then, close that ticket without asking any question at https://github.com/flatpak/flatpak/issues/6667 We are assuming good faith from that maintainer. Maybe my ticket was not clear.

-– — — — — — — — — — — — — — — —

ID

Ignore this line. This is a note to myself: ID_E3T4Z2C4

2

I would assume that the only issue here is an misunderstanding.

Yes, an Flatpak can gain default access to selected folders by having a filesystem permission set.

However, there is a second system to access user files, which is the FileChooser portal. As a very basic explanation: Over the portal, the application tells the system it wants to open or save a user-selected file. The system then shows the user the file picker, outside of the sandbox or control of the application, to pick the file. Then the system grants the application access to only the selected file.

Now, to the user, this process is transparent. Because the assumption is that a user would want an application to have access to a file they selected.
And since the portal access is granted separately over an secure process, it is not governed by the filesystem permissions. The application will still only be able to have access to the files you have granted it access to.

So, based on my reading of your issue, this should be a non-issue.

But, if you want to confirm the sandbox is really working, here is a quick test you can do:

Run flatpak run --command=bash org.freedesktop.Platform//25.08. The Freedesktop runtime has no permissions whatsoever. So, if you then try to access files from your home using ls or less or any other command inside the sandbox, it should not even able to know about the files.
If that is not the case, then there is an issue. Otherwise, it is likely the misunderstanding mentioned previously.

3

Hello @CodedOre . My replies are below.

But, if you want to confirm the sandbox is really working, here is a quick test you can do:

Run flatpak run --command=bash org.freedesktop.Platform//25.08.

Thanks for your suggestion :slightly_smiling_face: . I will try this when I am available. Then post the result here.

Yes, an Flatpak can gain default access to selected folders by having a filesystem permission set.

All global filesystem Flatpak permissions are denied. Same for the app filesystem Flatpak permissions. They are all denied. Detailed configuration about this is in my original post up above. Maybe my original post was not clear about this.

4

The sentence you quoted was mainly meant as part of the explanation that there are two ways a Flatpak can gain access to files. Maybe that could’ve been worded better.

Also, in your original post you did say you have set a filesystem permission for the application, for the documents folder.

5

@CodedOre Your information about the Debian file manager helped to narrow down the source of the challenge. Thanks again for that.

We were able to reproduce this challenge 100% of the time. On different devices. With multiple Flatpak apps. Which are not using the Debian file manager. Meaning those apps can directly access files outside their sandbox.

Per the apps maintainers’ preference, we are contacting them privately about that potential security vulnerability for their consideration and their decision. Waiting their reply.

Below is the same as above. But with details if you’re interested in those.

For reporting such potential security vulnerability, for stronger security, usually maintainers prefer to be informed privately. So that, if appropriate, they have an opportunity to adapt their security before the vulnerability is public. First, we’re trying this. Then, we will wait for their replies. Next, if appropriate, the maintainer might publish either all or part of their private ticket.

This challenge can only be reproduced when combining those 4 parts:

  1. Flatpak engine
    +
  2. Runtime(s)
    +
  3. Default permissions of the Flatpak app
    +
  4. Flatpak app

Using the same Flatpak apps, the challenge can’t be reproduced when testing only one part. This is normal. Because, most Flatpak apps combine those 4 parts up above.

Your other suggestion about flatpak run --command=bash org.freedesktop.Platform//25.08 was useful. Thanks again for that. Our test result is that both KDE runtime part or Freedesktop runtime part, when use alone, successfully blocked access to folders and files outside its own sandbox. Per above, all 4 parts are needed to reproduce this challenge.

About the Debian file manager. I learned something new. My updated understanding is that if a Flatpak app uses the Debian file manager to access folders or files. Then, the permissions are controlled by the file manager. Not by Flatpak. In other words, the file manager overrides and cancel the Flatpak permissions.

In my personal experience, with Debian 12, for the past years, the Debian file manager, somehow was not able to override and cancel the Flatpak permissions. This started a few weeks ago. According to XDG contributors, this is normal because the XDG packages, which power part of the Debian file manager, XDG was not yet stable enough to be able to override Flatpak permissions. One of the recent XDG update fixed this.

So the above rules out de Debian file manager has the cause of the challenge.

While at the same time, this rules in the combined 4 parts listed above as potential cause of the challenge.

In other words, we made some progress

Also, in your original post you did say you have set a filesystem permission for the application, for the documents folder.

Yes and no. I hope the following clarifies, per my original post:

  • Yes because the Flatpak apps are configured to ALLOW them to access folders and files WITHIN their sandbox.
  • No because the Flatpak apps are configured to NOT allow them to access folders and files OUTSIDE their sandbox.

The challenge is with the apps access to denied folders and files located outside their sandbox.

Anyhow, as you know, this challenge can also be reproduced with Flatpak apps that have no filesystem permission. Including, but not limited to, not allow access to Documents folder.