5 ms·

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 act

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.

fbdab103 3y ago
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.
- damsalor 3y ago
  Screen sharing works across the planet nowadays
- Dalewyn 3y ago
  >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.
- fsflover 3y ago
  > 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-meet-e-g-how-to-share-the-screen-of-a-different-qube-or-perhaps-hvm/24782 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 https://forum.qubes-os.org/t/create-a-gaming-hvm/19000 > Problems getting web cams or microphones working? These work reliable for me.
  - fbdab103 3y ago
    Thanks for those links. That GPU passthrough tutorial still looks like it is going to require some pain.
timeflex 3y ago
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.
- fransje26 3y ago
  > 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?
- fsflover 3y ago
  > 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-different-qubes/987 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-qubes-os-from-telegram/22934/111 https://forum.qubes-os.org/t/how-to-hide-the-fact-that-im-qu... (have a look at the whole topic, too).
tholdem 3y ago
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.
- akvadrako 3y ago
  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.
- minitech 3y ago
  (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.
- fsflover 3y ago
  > The template uses passwordless sudo This is easy to change: https://www.qubes-os.org/doc/vm-sudo/#replacing-passwordless-root-access-with-dom0-user-prompt https://www.qubes-os.org/doc/vm-sudo/#replacing-passwordless... and https://forum.qubes-os.org/t/replacing-passwordless-root-with-a-dom0-prompt/19074/18 https://forum.qubes-os.org/t/replacing-passwordless-root-wit... See also: https://forum.qubes-os.org/t/passwordless-sudo-selinux-understanding-security-logic/22446/2 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.

fbdab103 3y ago

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.

damsalor 3y ago
Screen sharing works across the planet nowadays
Dalewyn 3y ago
>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.
fsflover 3y ago
> 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-meet-e-g-how-to-share-the-screen-of-a-different-qube-or-perhaps-hvm/24782 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 https://forum.qubes-os.org/t/create-a-gaming-hvm/19000 > Problems getting web cams or microphones working? These work reliable for me.
- fbdab103 3y ago
  Thanks for those links. That GPU passthrough tutorial still looks like it is going to require some pain.

timeflex 3y ago

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.

fransje26 3y ago
> 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?
fsflover 3y ago
> 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-different-qubes/987 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-qubes-os-from-telegram/22934/111 https://forum.qubes-os.org/t/how-to-hide-the-fact-that-im-qu... (have a look at the whole topic, too).

tholdem 3y ago

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.

akvadrako 3y ago
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.
minitech 3y ago
(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.
fsflover 3y ago
> The template uses passwordless sudo This is easy to change: https://www.qubes-os.org/doc/vm-sudo/#replacing-passwordless-root-access-with-dom0-user-prompt https://www.qubes-os.org/doc/vm-sudo/#replacing-passwordless... and https://forum.qubes-os.org/t/replacing-passwordless-root-with-a-dom0-prompt/19074/18 https://forum.qubes-os.org/t/replacing-passwordless-root-wit... See also: https://forum.qubes-os.org/t/passwordless-sudo-selinux-understanding-security-logic/22446/2 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.