Sandboxing all the things with Flatpak and BubbleBox

Flatpak sandboxing & permission management

• Several commenters find Flatpak’s sandboxing useful but depend on GUIs like Flatseal or KDE’s Flatpak permissions panel; some say they might not use Flatpak without these.
• Others distrust third‑party GUIs controlling permissions, especially when installed as Flatpaks themselves, and would prefer distro‑packaged tools.
• There is confusion over Flatpak home/SSH deny rules; explanation given that !home and !~/.ssh are treated separately, so both are needed for safety.

Linux sandboxing mechanisms & philosophy

• Users highlight AppArmor, SELinux, seccomp, Landlock, systemd features, bubblewrap, and Flatpak as a fragmented but powerful sandboxing stack.
• Debate over pledge/unveil vs. MAC systems: one side says pledge/unveil are weaker and rely too much on developers; another argues they complement external policies by allowing privilege reduction over a process’s lifetime.
• One Rust library is mentioned that lets you sandbox your own code (e.g., calling C libraries) using namespaces, seccomp, and Landlock.

Critiques of Flatpak and bwrap UX

• Bubblewrap is praised as a strong primitive, but its raw CLI is considered awkward; some users manage it via custom shell scripts and aliases, others call for higher‑level tools like bubblebox or GUI frontends.
• A lengthy criticism of Flatpak raises: confusing app IDs, reliance on FUSE instead of newer kernel features, permissive defaults (e.g., host and /dev access), inflexible file mappings, awkward file forwarding (e.g., org.vim.Vim), overuse of flatpak-spawn that can punch holes in the sandbox, painful SDK/extension packaging, and strict Flathub moderation.
• Others counter that tools like portals and standardized permission dialogs are a step toward a more coherent desktop sandbox story.

Alternative isolation approaches (containers, Nix/Guix, Qubes)

• Some users prefer Podman or distrobox/toolbx containers for untrusted or closed‑source apps, or for CLI tooling, often based on Debian/Ubuntu or the host distro.
• NixOS and Guix are cited for reproducible builds and containerized FHS environments; there’s interest in per‑process immutable root filesystems built from a content‑addressed store, possibly with overlayfs.
• Qubes OS is described as offering strong isolation via many VMs, but with high RAM/GPU requirements and some template‑hardening trade‑offs.

Broader security concerns

• Several commenters argue desktop Linux security is weak in practice: lots of unsafe‑language code, little sandboxing by default, and reliance on users/distro policies.
• Others note that stronger defaults (e.g., SELinux, immutable/atomic distros, Android‑derived systems like GrapheneOS) show what more pervasive sandboxing can look like, though these come with usability and ideological trade‑offs.