this post was submitted on 12 Jun 2026
32 points (100.0% liked)

Privacy

49063 readers
1619 users here now

A place to discuss privacy and freedom in the digital world.

Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.

In this community everyone is welcome to post links and discuss topics related to privacy.

Some Rules

Related communities

much thanks to @gary_host_laptop for the logo design :)

founded 6 years ago
MODERATORS
 

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?

all 30 comments
sorted by: hot top controversial new old
[–] AnnaFrankfurter@lemmy.ml 4 points 11 hours ago (1 children)

I've been daily driving Qubes OS for last 6 years. You don't need to be an Linux expert but you should know basic things. And few common commands and maybe simple bash scripting if you want some level of customization

Main thing is divide your personas,and create a Qubes for each of them. and if you just want to search for some random shit use disposable VMs

My setup is something like this I've 3 debian and 3 fedora templates 1 minimal used for sys VMs and vault, 2 normal template here I only install packages only available in official debian/fedora, repos 3 in this template I add custom repos which are still trustworthy

Then depending on what I need in which app on I assign the template.

I'm forced to use zoom and other very intrusive apps for them I've just setup the rc.local script (this runs with start of any Qube) to install them

Also even though Qubes provides isolation at Qube level I still use firejail inside all the VMs it just takes few minutes to setup and gives a peace of mind

Also Hassel depends on what you use it for. Few pain points for me are

  1. Nested virtualization isn't possible* there are some workarounds and in most cases it's okay. The only problem is for Android app development. In that case the best solution is to just use adb and connect your own device

  2. PCI passthrough it was really terrible few years ago but now it works in most cases but for me sometimes my Laptop overheats. I don't need it much often so i haven't spent time to fix it.

[–] SleepyPie@lemmy.world 1 points 6 hours ago

Neat, thanks for the insight. I’ll try it out tomorrow, test out the personas

[–] communism@lemmy.ml 3 points 12 hours ago (1 children)

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.

[–] nebulahhh@lemmy.blahaj.zone 2 points 11 hours ago (1 children)

I have a gaming VM running cachyOS in Qubes OS and it runs pretty good, I'd still not recommend tho as qubes will randomly freeze (at least a few times a week) and I have to hold the power button and restart might be due to me using a nvidia GPU for dom0. (I use an AMD gpu for the gaming VM and I'm not sure how GPU passthrough will work with two AMD GPUS) It does work well tho

[–] communism@lemmy.ml 1 points 4 hours ago

I mean, I only have one GPU, so if passthrough is required then that does make gaming more inaccessible.

[–] pound_heap@lemmy.dbzer0.com 4 points 15 hours ago

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

[–] Amaterasu@lemmy.world 2 points 15 hours ago* (last edited 15 hours ago)

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...

[–] pp99@sh.itjust.works 10 points 1 day ago

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

[–] bbb@sh.itjust.works 7 points 1 day ago

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.

[–] ATS1312@lemmy.dbzer0.com 7 points 1 day ago

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.

[–] warmaster@lemmy.world 11 points 1 day ago (1 children)

I would try Secure blue first, if you are still comfy then try Qubes. Real security can be annoying. Test what's your limit.

[–] SleepyPie@lemmy.world 3 points 1 day ago

Thanks for the rec

[–] kat@lemmy.blehiscool.com 10 points 1 day ago (1 children)

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.

[–] SleepyPie@lemmy.world 3 points 1 day ago* (last edited 1 day ago)

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 as normal. If I hear anything bad about them I just nuke that qube right?

A little extra up front work, but way easier to maintain with much less at risk if something goes wrong?

[–] gary_host_laptop@lemmy.ml 4 points 1 day ago (2 children)

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.

[–] FineCoatMummy@sh.itjust.works 1 points 19 hours ago

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!

[–] wesker 4 points 1 day ago

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.

[–] jbloggs777@discuss.tchncs.de 4 points 1 day ago (1 children)

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.