The sandbox is only part of the security model
A fresh contribution to the long-running Flatpak security debate argues that the Linux application format's sandbox should be assessed separately from the permissions requested by individual programs. The essay, published by developer Oro, says Flatpak provides real isolation but that older or insufficiently adapted applications can weaken it by requesting broad static access to host resources.
Flatpak packages desktop applications with their dependencies and uses sandboxing to limit access outside the application environment. Portals provide controlled interfaces for operations such as choosing files or interacting with desktop services. In principle, that lets software request a specific user-mediated action instead of receiving permanent access to a large section of the host system.
The practical transition is incomplete. Applications originally designed for an unrestricted Linux desktop may depend on direct filesystem or service access, while some portal interfaces are not mature enough for every workload. Maintainers can compensate with static permissions, but each broad grant reduces the protection users expect from confinement. The essay's central claim is that this is a property of an application's packaging and design, not evidence that Flatpak lacks a sandbox altogether.
Partial isolation can still block malware behavior
As an example, the author points to analysis of the fractureiser malware campaign and the PrismLauncher Flatpak. Malware that assumed it could write directly to the user's configuration directory and invoke systemd would fail under the launcher's default Flatpak restrictions, the essay says. Writes aimed at an unavailable host path could remain inside temporary sandbox storage, while systemd was not exposed in the environment.
That example does not establish that every Flatpak application is secure. A package granted access to sensitive host directories, sockets or services can expose a much larger attack surface. Utilities that let users override permissions can also undermine defaults when grants are added without understanding their effect. The relevant question is therefore what a particular application can reach, rather than whether its package carries the Flatpak label.
The essay also rejects the idea that shared runtimes are necessarily left with stale security dependencies. It says runtimes can receive security updates independently and that major host-facing components, including graphics drivers, can be updated separately. Bundled libraries maintained inside an application can still require attention from its publisher, so update responsibility is divided across the platform, runtime and app.
This is an opinionated developer analysis, not a new vulnerability disclosure or an independent audit. Its useful contribution is a more precise framework for the argument. Flatpak supplies confinement mechanisms; portals can reduce standing access; applications choose or inherit permissions; and users and distributors need to inspect the resulting combination. Security depends on all of those layers, with partial isolation offering meaningful protection without making every package safe by default.
