Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Just wanted to add, though obliquely relevant to the OP, I have daily driven Qubes OS 4.1 for at least 12 months now and have been thoroughly impressed. It actually makes me feel safe[r] in my online computing today. 8chan or Discord -delivered 0-day blowing up in one of the respective qubes should not lead to exfiltration of my Robinhood credentials, my aunt's baking recipes, or my super secret hacker darknet forum libressl key. :^)

You want a beefy system. If you want to pass GPUs through, you need more than one in the system. CPU core count is important yes, but I cannot emphasize enough: RAM RAM RAM. Yes I do have automatic1111 running with GPU in my Qubes tower. Yes I can spin up a WinServ2022 Datacenter qube for Siemens NX 10, with full GPU support.



One thing that steered me away from QubesOS was that the templates used for all VMs were not hardened at all, instead, the Qubes Fedora template for example were less secure than a normal Fedora install. The template uses passwordless sudo and SELinux is completely removed. Security is about layers and the default templates are lacking in that sense. I want to make initial compromise as hard as possible. For QubesOS reasoning for not needing hardened templates to make sense, I would need to have a completely separate AppVM for each application and I don't think QubesOS was meant to be used like that.


> The template uses passwordless sudo

This is easy to change:

https://www.qubes-os.org/doc/vm-sudo/#replacing-passwordless...

and

https://forum.qubes-os.org/t/replacing-passwordless-root-wit...

See also: https://forum.qubes-os.org/t/passwordless-sudo-selinux-under...

Although I'm convinced that passwordless sudo helps a lot to make life easier for new Qubes users.

> For QubesOS reasoning for not needing hardened templates to make sense, I would need to have a completely separate AppVM for each application and I don't think QubesOS was meant to be used like that.

This is not necessary. You can group your apps with the same trust level in the same VM. Again, it's especially helpful to the new users. Advanced users like you, with strict threat models, can use minimal VMs to compartmentalize much more.


That sounds pretty good. Passwordless sudo and disabling SELinux are the first things I do on new Fedora installs.

If somebody can compromise my user account, compromising root is pointless and trivial. More so on Qubes OS, where only breaking out of the VM really matters.

SELinux isn't usable in a strict mode because it's config is so ungainly that devs rarely create profiles. So only the opt-in mode is common and that's pretty pointless. Especially compared to using containers.


(SELinux is enabled as of Fedora 39.)

> I would need to have a completely separate AppVM for each application and I don't think QubesOS was meant to be used like that.

I think that’s a decent starting point, actually. Not only that, but also separate disposable VMs for individual tasks, like reading a PDF.


Wouldn't passing through GPUs automatically provide enough information to tie all your VMs together? Unless someone has found a way to make GPUs pretend to be common consumer GPUs and not report any individualized fingerprints, then I would think that any online service that has GPU access can easily fingerprint you. Plus, in my experience VMs also tend to report a lot of system information that makes it apparent what hypervisor and virtual devices you are using.

Sure, each VM may be isolated in the sense that they each have their own apps and isolated file systems... but that is exactly what sandboxing does, except without the overhead of complete virtualization at each layer. I'd guess that Windows Sandbox would provide the same security in a much more efficient manner. On Linux, the integrated sandboxing solutions should also provide isolation like a VM but with better performance.

I understand Qubes design decision, but honestly think it is a bit antiquated and cumbersome when in reality you don't gain much compared to other solutions.


> I would think that any online service that has GPU access can easily fingerprint you.

Only Whonix provides a reliable protection against fingerprinting: https://forum.qubes-os.org/t/can-websites-track-me-across-di...

> in my experience VMs also tend to report a lot of system information that makes it apparent what hypervisor and virtual devices you are using

Hiding that is almost impossible: https://forum.qubes-os.org/t/how-to-hide-the-fact-that-im-qu... (have a look at the whole topic, too).


> bit antiquated and cumbersome when in reality you don't gain much compared to other solutions.

What would be other/better solutions that can be used for the same goal?


I am this close to rebuilding my machine in Qubes. Is 32GB enough RAM or am I going to be seeing usability issues?

The proliferation of AI tools really wants me to grab more of this wild-west code, but obvious security concerns there. Am I going to take a huge hit in performance if I am running this stuff in a virtual machine like llamafile which runs on the CPU?

Secondary GPU for pass through is less appealing, but I suppose I can stomach it. Is there a good guide on how you configured this? Many moons ago, before Proton was so good, I had looked into doing GPU pass through, but quickly gave up on the technical complexity.

Anything else notable? Problems getting web cams or microphones working? I assume you cannot screen share across Qubes.


> Is 32GB enough RAM or am I going to be seeing usability issues?

It should be sufficient for quite some time, until you run 15+ VMs simultaneously or so. I reach this limit only when I open too many https links each in its own VM.

> Am I going to take a huge hit in performance if I am running this stuff in a virtual machine like llamafile which runs on the CPU?

Anything relying on GPU gets significantly slower on Qubes (without the passthrough); ordinary apps relying in CPU are fast though.

> I assume you cannot screen share across Qubes.

You can: https://forum.qubes-os.org/t/while-video-streaming-google-me...

> Secondary GPU for pass through is less appealing, but I suppose I can stomach it. Is there a good guide on how you configured this?

https://forum.qubes-os.org/t/create-a-gaming-hvm/19000

> Problems getting web cams or microphones working?

These work reliable for me.


Thanks for those links. That GPU passthrough tutorial still looks like it is going to require some pain.


>Secondary GPU for pass through is less appealing, but I suppose I can stomach it.

Anyone using an Intel CPU from the past ~13 years or an AMD APU or Zen 4 CPU should have an iGPU to render the host with, unless they specifically opted out, leaving the GPU free for passthroughing.


Screen sharing works across the planet nowadays




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: