With all the supply chain attacks in the Linux ecosystem, isn’t the natural solution to move to full application sandboxing?
Flatpacking is great but not all applications support it.
Is it too much of a hassle?
I’ve never daily driven it as my main machine but I’ve used it as an auxiliary driver for a more high-security machine. Afaik things like gaming are sort of a no-go on Qubes still.
Qubes does not just do sandboxing. It runs all user programs in VMs, which adds non-negligible overhead and makes it an unsuitable OS for many more lightweight systems like laptops. And even if your PC can run Qubes without issue, you may not want that additional overhead if you want to do anything computationally intensive.
QubesOS is not meant for app sandboxing. Running each app in its own qube is very expensive, and hard to maintain. QubesOS are designed around the concept of domain compartmentalization, letting you to limit blast radius.
I use QubesOS for finance related stuff, and also thinking to use it for sysadmin tasks on my homelab. Daily driving it seems too complicated for me
No. Security and privacy are necessary but are nothing if not balanced with convenience. A little sacrifice of convenience is necessary but Qubes and even Secureblue passed the mark in my rule. This comes from one that has in its installation: LUKS, Secure boot, TPM PCR 7 verification, Apparmor.d updates and enforced, UFW, dnscrypt, run0, AIDE, Lynis, auditd, checking reproducible packages, etc…
I use it as a daily driver for years now. Just a few things to learn on top of regular linux and you are good to go. Feel free to ask anything.
You are more protected from supply chain attacks but I think it’s not a long term solution
I haven’t even tried it. GPU is too important these days. They recommend using a separate system entirely for GPU-intensive tasks. I actually do have that setup in a way, but only for the most GPU-intensive tasks. I don’t want to have to switch devices just to watch a video without draining half my battery.
It’s the GPU companies’ fault, of course, but that doesn’t change much.
deleted by creator
I adore Qubes!
Until a new version of Fedora gets EOLed. Or Qubes itself.
Setting up ALL of those distros every 3-6 months is a pain in the dick even when nothing goes wrong. And something always goes wrong with enough complexity.
I would try Secure blue first, if you are still comfy then try Qubes. Real security can be annoying. Test what’s your limit.
Thanks for the rec
You don’t necessarily need QubesOS to get better isolation. You can package unsupported applications as Flatpaks yourself and run them with minimal permissions. The downside is the maintenance burden, and Flatpak sandboxing isn’t as strong as Qubes’ VM-based isolation. It’s a useful middle ground, but it doesn’t completely solve supply-chain risk. Qubes can be good, but it’s all about your friction budget.
Humans optimise for convenience eventually.
Am I naive to think that Qubes would be less work?
I’d set up a few different qubes for the apps kind of like graphene and then just let them update. If I hear anything bad about them I just nuke that qube right?
A little extra up front work, but way easier to maintain?
A couple of tricks I use:
-
an apparmor profile tied to a shell script that wraps other commands … it restricts read & write access to a scratch directory … perfect for builds or one off scripts.
-
iptables rules & cgroups to restrict network access… I have a setuid wrapper that drops privs again…
-
bwrap and mounting only what’s necessary… quick to get going.
-
custom landlock wrapper, similar to apparmor but allows for quick userspace wrapping.
They can be combined too.
+1. May I add a few other help gizmos to that list?
- firejail. Super easy one off sandboxing. I have a bunch of aliases like “firejail --some-params – some-command-i-wanna-sandbox”.
- lxc. Middle weight sandboxing. Easy to get a console into it and have a whole OS env, which is nice sometimes. Much lighter than a KVM sandbox. But not quite as secure since it uses the same kernel. Super great to control network config for an app or group of similar apps. And easy to put a several related things into it that you wanna use all together. You can even use a separate VPN in each one.
-
I’ve always been curious about it, but felt like it might be a pain to try to use as a daily driver.
I’ve fairly thoroughly hardened my Void install, have an update and CVE audit workflow, and use firejail to sandbox any apps that make sense to sandbox. That feels more than enough for me.
The latest attack on the AUR would be solvable by Nix, in theory, Qubes would still suffer from this, only it’s compartmentalized, whereas Nix would be safe from my understanding.
The latest attack on the AUR
For anyone else like me who was OOTL, I guess that refers to this…
https://thehackernews.com/2026/06/over-400-arch-linux-aur-packages.html
If a flagged package ran, treat the host as credential-compromised. Rotate everything the stealer touches: browser sessions, SSH keys, GitHub and npm tokens, Slack, Teams and Discord sessions, Vault tokens, Docker and Podman credentials, and any cloud keys.
If the package ran as root, assume the rootkit is present and reinstall from trusted media. There is no way to trust the system otherwise.
Jeepers!
deleted by creator
This is not the same. The AUR was a supply chain attack, where good packages where replaced with malicious one’s.
Nix is better at stopping things like that from happening, becuase they have a monorepo, where most package updates or changes are reviewed by another person. The AUR is just a collection of individual git repos (or branches), where each maintainer can make updates or changes with no oversight.
Edit: this person knows their shit.
The original person you replied was commenting that nix was less vulnerable to supply chain attacks. Your reply is essentially completely off topic, talking about CVE’s. They are not the same type of issue. Having an actively running piece of malware on your system is vastly more concerning than a vulnerability someone has yet to exploit, and the supply chain security techniques needed to protect against the former are different as well.
Immutability is an extremely poor defense against any form of attack. Immutability is literally a filesystem feature where a flag,
chatttr -iis set on files or folders. Any program with root can adjust this flag, and any program running as a user could download additional binaries to or modify the users home directory. This is how the nix daemon works.Now, if nixos followed (or you configured it to follow) a model where only binaries in the nix store could be executed, and nothing else could be executed (in addition to maybe say, using selinux to enforce that only the nix daemon is editing the nix store), that would be much more secure and very interesting. But it’s not doing that.
Edit: correction, the nix store is not actually immutable on the filesystem level. It merely holds immutable “outputs”, the packages and functions it generates. You’re not supposed to edit them… but nothing stops you (if you’re root or the nix daemon user). You can verify the nix store pretty easily, but it’s not an ongoing process, that is to say it wouldn’t catch malicious changes.
What I said above about a theoretical applocker enabled like system based on Nix still applies, however.
Oooh. Thanks. This is a useful bit of info.
Thanks for your excellent reply complete with the schooling I needed.
how would nix be affected by an attack like the one in the aur? nix packages its own dependencies, which are then packaged into other packages. the attack on the aur was possible because some software called for a library to be downloaded somewhere and npm was affected which ended up affecting the aur. for it to work on nix someone would have to upload a malicious package into the nixpkgs, which im not saying its impossible, but at the bare minimum there’s a bigger barrier than basically 0 compared to the aur.
deleted by creator
i dont even use nix, i just know of it, you seemed like you knew more than me, so i tried to explain, doesn’t mean i was correct, i hoped you could maybe correct me, but sure
deleted by creator
deleted by creator
