Firefox Flatpak Sandbox Permissions and Portal Limitations

Running the Firefox Web Browser as a Flatpak on Linux enhances system security by isolating the browser from the rest of the operating system. This article provides a straightforward breakdown of the default sandbox permissions granted to the Firefox Flatpak, how it relies on XDG Desktop Portals for system integration, and the specific limitations users face regarding native messaging, hardware access, and file management.

Default Sandbox Permissions

Out of the box, the official Firefox Flatpak is configured with a strict set of permissions to ensure it can function as a modern web browser without exposing the host system. By default, the sandbox allows the following access:

  • Network Access: Full access to the network (--share=network) to browse the web.
  • Display Servers: Access to Wayland (--socket=wayland) and X11 (--socket=fallback-x11) to render the browser window.
  • Audio: Access to PulseAudio (--socket=pulseaudio), which also routes through PipeWire on modern distributions, allowing audio playback and microphone input.
  • Graphics Acceleration: Direct Rendering Infrastructure (--device=dri) access for hardware-accelerated video decoding and WebGL.
  • Filesystem Access: Read and write access is restricted strictly to the user's Downloads directory (xdg-download). The browser cannot see the rest of your home folder or system files by default.
  • IPC and Shared Memory: Inter-process communication (--share=ipc) is enabled for performance and stability.

How Portals Bypass Sandbox Restrictions

Because the sandbox blocks direct access to the host system, Firefox relies on XDG Desktop Portals to perform standard desktop actions securely. Portals act as a middleman, prompting the user for permission before granting Firefox temporary access to a resource.

  • File Chooser Portal: When you upload or save a file outside the Downloads folder, Firefox triggers the host system's native file manager dialog. Once you select a file, the portal passes ONLY that specific file into the Firefox sandbox.
  • ScreenCast Portal: For screen sharing on Wayland, Firefox uses the ScreenCast portal alongside PipeWire. This prevents the browser from silently recording your screen without explicit confirmation.
  • Print Portal: Printing requests are handed off to the host's CUPS server via the print portal, meaning Firefox does not need direct access to printer drivers.

Key Limitations of the Firefox Flatpak

While the sandbox and portal system works well for general browsing, it introduces significant limitations for advanced use cases and system integration.

1. Broken Native Messaging (Browser Extensions)

Many popular browser extensions rely on "Native Messaging" to communicate with software installed on the host system. Because the Flatpak sandbox blocks Firefox from executing or talking to host binaries, extensions that require a companion app will fail to work out of the box. This affects:

  • Password Managers: Extensions like KeePassXC-Browser cannot easily communicate with the KeePassXC application on the host.
  • Desktop Integration: The GNOME Shell Integration extension (used to install GNOME extensions via the browser) and Plasma Integration will not detect the host desktop environment.
  • Download Managers: External download managers cannot intercept browser traffic through companion extensions.

2. Smart Cards and PKCS#11 Modules

While the Firefox Flatpak includes access to the PC/SC daemon (--socket=pcsc) for basic smart card access and supports FIDO2/WebAuthn USB security keys, advanced enterprise authentication often fails. Smart cards that require custom PKCS#11 driver modules (.so files) installed on the host system's /usr/lib directory cannot be loaded by Firefox, as the Flatpak uses its own isolated /usr runtime.

3. Opening Downloaded Files

When you download a file and click it inside Firefox's download manager to open it, Firefox uses the OpenURI portal to launch the appropriate host application. However, if the host application is also a Flatpak, or if the file was saved to a temporary directory inside the Firefox sandbox (~/.var/app/org.mozilla.firefox/cache/), the external application may fail to open the file because it lacks permission to read inside Firefox's private sandbox storage.

4. Drag and Drop Issues

Dragging and dropping files from a host file manager into the Firefox window relies on the File Transfer portal. Depending on the desktop environment and whether you are using X11 or Wayland, dragging files from restricted directories directly into web apps (like Google Drive or webmail) can occasionally fail or result in zero-byte uploads.

5. Isolated Profile Storage

The Flatpak version does not use the traditional ~/.mozilla/firefox directory. Instead, all user profiles, caches, and configurations are stored in ~/.var/app/org.mozilla.firefox/. Tools on the host system designed to back up, clean, or sync your Firefox profile will not find the browser data unless manually pointed to the Flatpak directory.

6. Customizing Permissions

Users can manually override some of these limitations using the flatpak override command or a graphical tool like Flatseal. For example, granting filesystem=home solves file access and drag-and-drop issues, while exposing the D-Bus session can fix certain extension integrations. However, doing so punches holes in the sandbox, reducing the security benefits of running Firefox as a Flatpak in the first place.