5 ms·

I've been using QubesOS for years, and I highly recommend it. Not only for security (which of course), but also for the cleanliness of not polluting your comput

by ghgr 3y ago

I've been using QubesOS for years, and I highly recommend it. Not only for security (which of course), but also for the cleanliness of not polluting your computer with a myriad of dependencies for projects you just tried once. And of course, the high-risk activities that we all have to do at some point (now at least their risk is limited to their virtual machine) : - curl|bash or similar - pip install, npm install etc - run any random github project - sudo install the drivers of my Brother printer - install zoom - plug random cheap USB devices to eg update their firmware

Always_Anon 3y ago
Why not just do all that in a throwaway container?
- fsflover 3y ago
  Hardware virtualization is much more secure.
  - Always_Anon 3y ago
    Not any more it isn't. Rootless non-root containers are about as secure as VMs today.
    - fsflover 3y ago
      Last time VT-d virtualization was escaped was in 2006 and done by the Qubes founder herself: https://en.wikipedia.org/wiki/Blue_Pill_(software) https://en.wikipedia.org/wiki/Blue_Pill_(software) How is it about the containers?
      - Always_Anon 3y ago
        >Last time VT-d virtualization was escaped was in 2006 and done by the Qubes founder herself: Have you been living under a rock [0]? >How is it about the containers? Container security aka OS virtualization has been quite secure for a while now. [0] https://www.csoonline.com/article/551445/significant-virtual-machine-vulnerability-has-been-hiding-in-floppy-disk-code-for-11-years.html https://www.csoonline.com/article/551445/significant-virtual...
        fsflover 3y ago
        > Have you been living under a rock [0]? I think you don't understand: Qubes relies on hardware, not software virtualization: https://en.m.wikipedia.org/wiki/Hardware-assisted_virtualization https://en.m.wikipedia.org/wiki/Hardware-assisted_virtualiza...
        Always_Anon 3y ago
        I think you don't understand. Qubes relies on software virtualization in conjunction with hardware assisted virtualization instruction sets. The aforementioned vulnerability existed in Qubes Xen.
        deleted 3y ago
        [deleted]
        fsflover 3y ago
        It seems the aforementioned vulnerability (XSA-133) didn't even affect Qubes: https://www.qubes-os.org/security/xsa/ https://www.qubes-os.org/security/xsa/. Also, such vulnerabilities were the reason for them to switch to VT-d by default: https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-030-2017.txt https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qs.... I'm not an expert, but how could it affect the VT-d even in principle? AFAIK VM escape is impossible with software exploits in this case, only side-channel attacks are.

by ghgr 3y ago

Always_Anon 3y ago

Why not just do all that in a throwaway container?

fsflover 3y ago
Hardware virtualization is much more secure.
- Always_Anon 3y ago
  Not any more it isn't. Rootless non-root containers are about as secure as VMs today.
  - fsflover 3y ago
    Last time VT-d virtualization was escaped was in 2006 and done by the Qubes founder herself: https://en.wikipedia.org/wiki/Blue_Pill_(software) https://en.wikipedia.org/wiki/Blue_Pill_(software) How is it about the containers?
    - Always_Anon 3y ago
      >Last time VT-d virtualization was escaped was in 2006 and done by the Qubes founder herself: Have you been living under a rock [0]? >How is it about the containers? Container security aka OS virtualization has been quite secure for a while now. [0] https://www.csoonline.com/article/551445/significant-virtual-machine-vulnerability-has-been-hiding-in-floppy-disk-code-for-11-years.html https://www.csoonline.com/article/551445/significant-virtual...
      - fsflover 3y ago
        > Have you been living under a rock [0]? I think you don't understand: Qubes relies on hardware, not software virtualization: https://en.m.wikipedia.org/wiki/Hardware-assisted_virtualization https://en.m.wikipedia.org/wiki/Hardware-assisted_virtualiza...
        Always_Anon 3y ago
        I think you don't understand. Qubes relies on software virtualization in conjunction with hardware assisted virtualization instruction sets. The aforementioned vulnerability existed in Qubes Xen.
        deleted 3y ago
        [deleted]
        fsflover 3y ago
        It seems the aforementioned vulnerability (XSA-133) didn't even affect Qubes: https://www.qubes-os.org/security/xsa/ https://www.qubes-os.org/security/xsa/. Also, such vulnerabilities were the reason for them to switch to VT-d by default: https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-030-2017.txt https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qs.... I'm not an expert, but how could it affect the VT-d even in principle? AFAIK VM escape is impossible with software exploits in this case, only side-channel attacks are.