While browsing this forum and other similar communities, I have often come across claims that the Flatpak sandbox is weak. However, this is usually not followed up with an explanation of how or why it is weak.
I am speaking only about the sandbox between the host and the application, not about the application’s ability to provide its own sandboxes (e.g. site isolation). Also, I am only referring to the sandbox in its default state (no added permissions) or the state of some applications that I will provide as examples. The reason that I am clarifying this is because the only decently detailed explanation of potential sandbox weakness that I have seen relies on the poor default permissions of popular applications (https://hanako.codeberg.page).
I am wondering if there are other resources that outline actual sandbox weaknesses in Flatpak’s architecture or with any of the permissions enabled in the following applications:
I was wondering why ppl say that flatpaks aren’t supposed to be used because of its weak sandboxing but it’s required to be used on secureblue/silverblue, that is supposed to be asecured Linux distro.
For me it doesn’t make much sense but I’ll confess that I didn’t make much research on the topic. I only can quote what RKNF404 said in his repo Chromium Hardening Guide
As mentioned in the Brave section, AVOID! Flatpak’s security is… questionable for a number of reasons, but what’s worse is chromium’s security in Flatpak. Because Flatpak restricts the usage of Linux namespaces and prevents the use of SUID (for good reason), chromium’s sandbox will literally not work. The solution is zypak or a direct patch, the problem is these methods are very poorly configured to the point they essentially break the typically very strong sandboxing chromium provides. These solutions are closer to compatibility layers than they are genuine security solutions. Upstream (chromium devs) have expressed they do no intend to support Flatpak anytime soon for reasons alike to this. Flatpak significantly inhibits chromium’s sandboxing, and there is no faithful implementation currently.
AFAIK Flatpak only weakens the sandboxing of (Chromium and Firefox based) web browsers. I haven’t seen anyone argue that Flatpak shouldn’t be used for other applications due to security reasons.
Warning:
Many Flatpak applications available on flathub are not effectively sandboxed by default [1]. Do not rely on the provided process isolation without first reviewing the related flatpak permission manifest for common sandbox escape issues.
Running untrusted code is never safe; sandboxing cannot change this.
The myth that flatpak apps provide a sandboxed environment is an illusion. Flatpaks are containerized applications that provide limited isolation by default and should be described as such.
Most of the concerns are due to applications being able to declare their own constraints and defaulting to bad presets, and not the actual separation between the host and the application. You can use flatseal to improve flatpak isolation.
When I used linux I found a few apps that wouldn’t work without outrageous permisions (home directory), I guess since so much of it is optional some developers just don’t take flatpak sandboxing into account when creating their apps, something you can’t do when making android apps for example.
Network access allows access to abstract sockets. For example to X11/Xwayland and dbus abstract sockets. Haven’t checked, if Xwayland in Gnome/KDE currently uses abstract sockets for Xwayland or if you would need to completely remove Xwayland. Don’t know if there is a specific solution to dbus abstract sockets. A general solution to remove access to abstract sockets could be to use a separate network namespace.
DRI used to be a problem for sandboxes. Don’t know, if this is still the case. Chromium considers RCE in the GPU process available through a renderer process a sandbox escape.
Gives unrestricted access to microphone and sound, even outside the sandbox.
Edit: I should add, that, depending on the configuration of the X11/Xwayland server, denying access to $XAUTHORITY could be enough to block access to it.
Have not faced this yet, but I will admit my usecase for desktop linux is just a development and browsing machine, no media work. Usually, denying home and adding relevant locations (like /etc/app_name or whatever) helps me. Same with invasive permissions like pulseaudio and IPC, most apps I use work without them.