I like the concept of sandboxing, of device manager and restricted user, in certain cases it can be really useful to implement, and I’d like to try doing something like that on desktop.
I would install Android directly but desktop apps are usually superior in many ways.
At the same time I think stuff like qubes OS is too much…
Maybe leveraging flatpaks or docker can be a solution, toolboxes too?
I’ve also tried Nixos but I don’t think it is what I’m looking for.
You must log in or # to comment.
There is no distribution that does what you’re looking for. All the ones recommended by others in this thread are just generic distributions that do nothing special to separate user applications and I have no idea why they saw fit to mention them at all.
The best recommendation here is Qubes but that’s arguably not a distro but rather its own operating system that can then run some instances of distros inside of it with strong separation between those units.
The only thing that somewhat goes the direction you want is Flatpak but it’s not anywhere close to Androids really quite solid app separation scheme.
The reality of it is that most Linux desktop apps are made with the assumption that they are permitted to access every resource the user has access to with no differentiation; your SSH or GPG private keys are in the same category as the app’s config file.
Standard APIs to manage permissions in a more fine-grained manner are slowly being worked on (primarily by the flatpak community IME) but it’s slow and mostly focused on container stuff which I’m not convinced is the way forward. There does not appear to be any strong effort towards creating a resource access control design that’s anywhere near as good as Android’s in any case though.
The closest thing we have is systemd hardening for system components but that’s obviously not relevant for desktop apps. It’s also (IMHO) inherently flawed due to using a blocklist approach rather than an allow-list one. It’s also quite rigid in what resources it controls.
I’m not convinced any of the existing technologies we have right now is fit for a modern user-facing system.
Here’s what I think we ought to have:
- A method to identify applications at runtime (e.g. to tell apart your browser from your terminal and your editor at runtime)
- A generic extensible way to declare resources to which access should be controlled within a single user context (i.e. some partition of your home filesystem or some device that your user generally has access to such as your camera)
- A user-configurable mapping between resources and applications; enforced by kernel-level generic mechanisms
No need for any containers here for any of this; they’re a crutch for poor legacy distro design that relies on global state. I don’t see a need for breaking the entire UNIX process model by unsharing all resources and then passing in some of them through by overly complex methods either.
Eventhough they’re quite simple and effective, I’m not convinced UNIX users are a good primitive to use for application identification like Android does it because that implies user data file ownership needs to be managed by some separate component rather than the standard IO operations that any Linux apps ever uses for everything.
I think this should instead be achieved using cgroups instead which are the single most important invention in operating systems that you can actually use today since UNIX IMHO.The missing parts are therefore a standard for resource declaration and a standard and mechanism to assign them to applications (identified via cgroup).
I haven’t done much research into whether these exist or how they could me made to exist.You’re looking for QubesOS.
Qubes OS is a free and open-source, security-oriented operating system for single-user desktop computing. Qubes OS leverages Xen-based virtualization to allow for the creation and management of isolated compartments called qubes.
Everything runs in its own sandbox called a “qube.” Read more.
Qubes is so good! Its compatibility is a bit limited, in my experience - some systems don’t run it and others would have issues, but if it works on your computer, it’s amazing.
Fedora Atomic?
Fedora CoreOS is meant to be just for containers if you want to go this route.
Yeah, it seems like these immutable distros with individually contained apps (maybe with some additional restrictions and hardening) are similar to what OP wants. There’s a lot of distros like this
Distrobox perhaps? Not sure about the android side of things. For true “sandboxing” something like docker is probably your best bet.
Pick your spin
Might be controversial as it is usually intended for gaming but: Bazzite (Gnome Edition). It is like Fedora Silverblue but has distrobox and virtualization baked in without fiddling AND… built in Waydroid so you can run Android apps. I am incredibly impressed with it.
That is not relevant here in any way. That’s a distro made to easily run one app at a time without really caring about data security w.r.t. that app.
He specifically mentions containerization, Flatpaks, Docker and Toolboxes, which these suggested Fedora Spins are designed to integrate with as tightly as possible, so completely relevant.
Also, Bazzite is completely the opposite of an OS designed to run one app at once, which means you haven’t tried it before rubbishing it as a suggestion.
p.s. Don’t take this the wrong way but the phrasing in your comments here make them sound quite aggressive and could lead them to be interpreted in the wrong way. Would you speak to someone like that on the street?
He
I hate to be that guy but OP gave no indication of their gender. English has the luxury of having a “natural” neutral pronoun; please just use that.
which these suggested Fedora Spins are designed to integrate with as tightly as possible
Could you explain what exactly this “tight integration” pertains? AFAIK these are just regular old global-state distros but with read-only snapshotting for said global state (RPM-ostree, “immutable”).
Read-only global system configuration state in pretty much requires usage of Flatpak and the like for user-level package application management because you aren’t supposed to modify the global system state to do so but that’s about the extent that I know such distros interact with Flatpak etc.Bazzite is completely the opposite of an OS designed to run one app at once, which means you haven’t tried it before rubbishing it as a suggestion.
That is their one and only stated goal: Run games.
I don’t know about you but I typically only run one game at a time and have a hard time imagining how any gaming-focused distro would do it any other way besides running basic utilities in the background (i.e. comms software.).
Obviously you can use it to do non-gaming stuff too but at that point it’s just a regular old distro with read-only system state. You can install Flatpak, distrobox etc. on distros that have mutable system state too for that matter.
Could you point out the specific concrete things Bazzite does to improve separation between applications beyond the sandboxing tools that are available to any distribution?
It’s true that I haven’t used Bazzite; I have no use for imperative global state distributions and am capable of applying modifications useful for gaming on my own. It’s not like I haven’t done my research though.
I hate to be that guy
That’s okay. Don’t be.
but OP gave no indication of their gender.
This is unnecessary white-knight pseudo-concern-trolling designed to derail from the topic at hand. This isn’t a conversation about gender. If I misgendered dontblink, I’ll send 5$ as an apology. You don’t, however, get to choose the language I use, as I equally don’t get to choose yours. Now, back to the Linux discussion:
Could you explain what exactly this “tight integration” pertains? AFAIK these are just regular old global-state distros but with read-only snapshotting for said global state (RPM-ostree, “immutable”).
Certainly. That’s essentially absolutely correct. In the case of Bazzite specifically:
- Distrobox comes pre-installed, enabling application installation inside sandboxed Podman containers with restricted access to
/dev. Unlike Toolbox, Distrobox can be configured with different and fully isolated home folders, meaning containers won’t have access to your GPG/SSH keys or other user files unless explicitly configured. - ujust is pre-installed (docs), providing helper scripts for various tasks, including easy virtualization setup for virt-manager/qemu/kvm for running completely isolated operating systems.
- BoxBuddy is pre-installed, a GUI for easy management of distrobox containers, also allowing you to alias/sync
.desktopfiles from sandboxes to your main home folder, allowing you to start sandboxed GUI apps from your normal GNOME/KDE menu. - Waydroid integration can be added via
ujust, allowing launching of sandboxed, isolated Android apps directly from the desktop environment.
That is their one and only stated goal: Run games.
That’s incorrect. While gaming is their primary focus—especially with the “big-screen” edition that boots directly into Steam—Bazzite also offers fully functional, polished desktop environments with thoughtful defaults. For example, even if only an insignificant tweak, GNOME on Bazzite has minimize/maximize buttons enabled by default (unlike Fedora Silverblue). It also supports developer workflows and even isolated, containerized systemd services. (docs). They offer Bazzite editions which boot directly to the desktop environment as default, leaving Steam as only a normal Flatpak application.
Could you point out the specific concrete things Bazzite does to improve separation between applications beyond the sandboxing tools that are available to any distribution?
None, beyond having them pre-installed out of the box. But it’s important to distinguish that dontblink asked for a solution, not the solution. I suggested Bazzite GNOME because it provides a nearly complete setup without needing to manually mess with
rpm-ostreefirst. Everything it can do can also be done on other similar immutable systems with a little extra work.- Distrobox comes pre-installed, enabling application installation inside sandboxed Podman containers with restricted access to
