Determine what to do with existing /.flatpak-info behaviour #21

New Issue

ophestra · 2025-11-05T22:35:55+09:00

ophestra commented

2025-11-05 22:35:55 +09:00

Flatpak currently places a file at /.flatpak-info in each container's mount namespace, in a way which makes it impossible for confined processes to manipulate the contents or existence of this file.

This does not appear to be documented as a security feature (correct me if I am wrong). However, many well-known programs access it through proc_pid_root(5) to authenticate applications connecting through a directly exposed UNIX socket. This has several issues:

PIDs are vulnerable to a race condition, where when the child process terminates, another process could wrap the PID around to take its place with the same PID.
The proc_pid_root(5) symbolic link is guarded behind PTRACE_MODE_READ_FSCREDS, making it inaccessible across UIDs, and therefore incompatible with hakurei's UID isolation.
A container process can manipulate its own vfs state by entering a new mount namespace it owns, breaking the guarantees that /.flatpak-info supposedly provides. Flatpak's workaround for this is to disallow namespace creation entirely and instead expose partial namespace functionality over dbus. This is unacceptable as it allows the privileged side of the sandbox tool to accept untrusted user input. It also significantly limits functionality and requires extensive patching or (arguably quite hacky) workarounds, all of which introduce additional code, contributing to the already significantly enlarged attack surface on both sides of the sandbox.
This behaviour is specific to Flatpak and does not have the same degree of stability guarantees of a proper established standard, although standards surrounding this are in rather sad states as well.

Some examples of this behaviour:

GNOME mutter, in the function meta_window_update_flatpak_id.
PipeWire, in the functions check_flatpak and pw_check_flatpak.
xdg-desktop-portal, in the function open_flatpak_info.

These programs always run in a less confined context than the application initial process, enabling confused deputy attacks in all of the above cases.

Notably, most Wayland servers do not suffer from this flaw, as they implement the security context protocol, allowing clients to connect through hakurei. PipeWire eventually requires a proxy regardless of this behaviour, as it offers very little security when directly exposed to the container. And finally, xdg-desktop-portal was never useful to begin with, as many of its design choices make it fundamentally incompatible with UID isolation, and some others make it inherently flatpak-specific. A workaround is not required in this case since an entirely new system is required anyway.

This ticket aims to keep track of all known instances of this behaviour, determine what we can do about it, and what we can contribute back to the wider community.

Flatpak currently places a file at `/.flatpak-info` in each container's mount namespace, in a way which makes it impossible for confined processes to manipulate the contents or existence of this file. This does not appear to be documented as a security feature (correct me if I am wrong). However, many well-known programs access it through `proc_pid_root(5)` to authenticate applications connecting through a directly exposed UNIX socket. This has several issues: - PIDs are vulnerable to a race condition, where when the child process terminates, another process could wrap the PID around to take its place with the same PID. - The `proc_pid_root(5)` symbolic link is guarded behind `PTRACE_MODE_READ_FSCREDS`, making it inaccessible across UIDs, and therefore incompatible with hakurei's UID isolation. - A container process can manipulate its own vfs state by entering a new mount namespace it owns, breaking the guarantees that `/.flatpak-info` [supposedly](https://github.com/flatpak/flatpak/commit/a10f52a7565c549612c92b8e736a6698a53db330) provides. Flatpak's workaround for this is to disallow namespace creation entirely and instead expose partial namespace functionality over dbus. This is unacceptable as it allows the privileged side of the sandbox tool to accept untrusted user input. It also significantly limits functionality and requires [extensive patching](https://github.com/flathub/org.chromium.Chromium/blob/cfdcea120b34829f01efbcf7445c29f5d03e40e7/patches/chromium/flatpak-Add-initial-sandbox-support.patch) or (arguably quite hacky) [workarounds](https://github.com/refi64/zypak), all of which introduce additional code, contributing to the already significantly enlarged attack surface on both sides of the sandbox. - This behaviour is specific to Flatpak and does not have the same degree of stability guarantees of a proper established standard, although standards surrounding this are in rather sad states as well. Some examples of this behaviour: - [GNOME mutter](https://gitlab.gnome.org/GNOME/mutter), in the function [meta_window_update_flatpak_id](https://gitlab.gnome.org/GNOME/mutter/-/blob/3ce48d0153df09e289106c74333d31ca18875039/src/core/window.c#L937-958). - [PipeWire](https://gitlab.freedesktop.org/pipewire/pipewire/), in the functions [check_flatpak](https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/fc55ceb2f44a60233c9715bb03a96330b06f20ef/src/modules/module-protocol-pulse/utils.c#L79-123) and [pw_check_flatpak](https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/fc55ceb2f44a60233c9715bb03a96330b06f20ef/src/modules/flatpak-utils.h#L66-144). - [xdg-desktop-portal](https://github.com/flatpak/xdg-desktop-portal/), in the function [open_flatpak_info](https://github.com/flatpak/xdg-desktop-portal/blob/6eac6171bc269b5e6cccd56e1d3c966ba50ca2a9/src/xdp-app-info-flatpak.c#L642-L698). These programs always run in a less confined context than the application initial process, enabling confused deputy attacks in all of the above cases. Notably, most Wayland servers do not suffer from this flaw, as they implement the [security context](https://wayland.app/protocols/security-context-v1) protocol, allowing clients to connect through hakurei. PipeWire eventually requires a proxy regardless of this behaviour, as it offers very little security when directly exposed to the container. And finally, `xdg-desktop-portal` was never useful to begin with, as many of its design choices make it fundamentally incompatible with UID isolation, and some others make it inherently flatpak-specific. A workaround is not required in this case since an entirely new system is required anyway. This ticket aims to keep track of all known instances of this behaviour, determine what we can do about it, and what we can contribute back to the wider community.

👍 1

ophestra referenced this issue

2025-11-05 22:36:26 +09:00

.flatpak-info/bwrapinfo.json emulation #2

ophestra referenced this issue

2025-11-05 22:36:45 +09:00

PulseAudio client sends its pid to the server #20

ophestra pinned this 2025-11-05 22:38:21 +09:00

ophestra added the

Kind

Feature

Priority