| by Arround The Web | No comments

When Flatpak’s Sandbox Cracks: Real‑Life Security Issues Beyond the Ideal

When Flatpak’s Sandbox Cracks: Real‑Life Security Issues Beyond the Ideal

Introduction

Flatpak promises a secure runtime for Linux applications through container-like isolation, relying on bubblewrap namespaces, syscall filtering, and portal interfaces. In theory, each app should operate inside a strong sandbox, disconnected from the host system. But in reality, experience shows gaps, tiny cracks through which apps may escape with serious consequences.

The Sandbox Promise… and the Reality

Flatpak applications begin life in a highly-restricted environment: no network by default, no access to host files beyond the runtime and a private data directory, limited syscalls, and restricted access to session or system services. Portals provide a controlled channel for granting specific capabilities (e.g. file dialogs, screenshot, printing) without broad privileges.

Yet, many Flatpak packages declare broad permissions like filesystem=home, filesystem=host, or device=all. That effectively grants full read-write access to the user's home directory or even system devices, defeating the purpose of the sandbox in practice. Users often assume that 'sandboxed' means locked-down, but blanket permissions expose them to risk.

Real-World Breakouts from the Sandbox

CVE‑2024‑32462: RequestBackground Portal Abuse

Security researcher Gergo Koteles uncovered a high-severity vulnerability where malicious Flatpak apps could craft a .desktop file via the org.freedesktop.portal.Background.RequestBackground interface. That tricked Flatpak’s --command= parsing into injecting bwrap arguments (e.g. --bind). This allowed arbitrary host commands to execute outside the sandbox boundary. Versions before 1.10.9, 1.12.9, 1.14.6, and 1.15.8 were affected. Patched in the listed versions and mitigated in xdg-desktop-portal 1.18.4 and newer.

CVE‑2024‑42472: Persistent Data Symlink Exploit

A Flatpak flag, --persist (or persistent= in manifest), allows apps writable storage within their data directory. But if a malicious install replaces that directory with a symlink pointing to sensitive host folders (e.g. ~/.ssh), the sandbox mount entry follows it into the real filesystem, giving the app unintended access to files outside its name-spaced area. All versions up to 1.14.8 and 1.15.x ≤ 1.15.9 are vulnerable; patched in 1.14.10 and 1.15.10+.

Policy Complexity and Ecosystem Slip-Ups

A detailed study of hundreds of Flatpak and Snap packages found that nearly 42% of Flatpak apps either override the supposed isolation or misconfigure sandboxing, resulting in overprivilege or potential escape paths. Crafting fine-grained sandbox policy is hard, and mistakes slip through easily.

Share Button

Source: Linux Journal - The Original Magazine of the Linux Community