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

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


Why not just do all that in a throwaway container?


Hardware virtualization is much more secure.


Not any more it isn't. Rootless non-root containers are about as secure as VMs today.


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)

How is it about the containers?


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


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


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.


It seems the aforementioned vulnerability (XSA-133) didn't even affect Qubes: 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/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.




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

Search: