5 ms·

What about security? I always thought that it's easy to get into vm from host, but it way harder to get to host from vm. I thought about using VM for security t

What about security? I always thought that it's easy to get into vm from host, but it way harder to get to host from vm. I thought about using VM for security things, but the idea that it easy to get inside vm keeps me from doing it

deleted 4y ago
[deleted]
andrey_utkin 4y ago
> I always thought that it's easy to get into vm from host, but it way harder to get to host from vm That's right. > but the idea that it easy to get inside vm keeps me from doing it No! Of course the host is the ultimate dictator. Just don't do untrusted operations in the host context. Have low-trust, low-connectivity, low resource level VM for untrusted work.
no-dr-onboard 4y ago
You might have it backwards. Most people typically do untrusted actions inside the VM and keep their host “clean”. You’re correct though that VM escapes are pretty difficult, especially with modern, patched microcode processors.
- a1xndr 4y ago
  > VM escapes are pretty difficult, especially with modern, patched microcode processors Most VM escapes happen through buggy virtual-devices written in C/C++/.. code. Virtual-device bugs that are exploitable by attackers with root access in the VM are found frequently.
  - fsflover 4y ago
    It's not frequent at all with Qubes hardware virtualization: https://www.qubes-os.org/security/xsa/ https://www.qubes-os.org/security/xsa/.
- danuker 4y ago
  > modern, patched microcode processors This makes me wonder how many security holes CPUs have which have been buried into secrecy by the manufacturers.
fsflover 4y ago
You are right. The host on Qubes OS (dom0) has no networking and never runs any software by default. Also, hardware virtualization which Qubes uses last time was broken in 2006 by its founder: https://en.wikipedia.org/wiki/Blue_Pill_(software) https://en.wikipedia.org/wiki/Blue_Pill_(software).
- jeroenhd 4y ago
  The hypervisor problem can be solved (in theory) with secure boot configured with custom keys and full disk encryption. I don't know anyone who actually uses Qubes so I don't know how practical that solution is. Coreboot has something similar to secure boot, so even if you use an open source boot loader, this can be done. An attacker would need to do some quite invasive hardware tampering to get a third party hypervisor to work on a system secured like that. Furthermore, preventing hypervisor detection requires constant updates if the OS itself is configured to check for the presence of a hypervisor. There's a constant arms race going on between security researchers and cybercriminals who don't want their malware to trigger on analysts' machines, many of which use virtualization to easily reset the system back to a known, secure state. Every time malware comes up with a new method of detection your evil hypervisor needs to be patched to fake that stuff too or you risk detection next time the OS updates its detection algorithms.
  - fsflover 4y ago
    This should work with Qubes quite well: https://puri.sm/posts/pureboot-101-first-boot-first-update-and-detecting-software-tampering/ https://puri.sm/posts/pureboot-101-first-boot-first-update-a... See also: https://forum.qubes-os.org/t/verified-boot-on-qubes-a-lofty-dream/2524 https://forum.qubes-os.org/t/verified-boot-on-qubes-a-lofty-...
- LanternLight83 4y ago
  I just wish Qubes had a simpler architecture, such that dom0 and the Qubes Components could be implemented in eg. Guix or Nix instead of a traditional distro. Love Qubes' desktop integrations.

deleted 4y ago

[deleted]

andrey_utkin 4y ago

> I always thought that it's easy to get into vm from host, but it way harder to get to host from vm That's right. > but the idea that it easy to get inside vm keeps me from doing it No! Of course the host is the ultimate dictator. Just don't do untrusted operations in the host context. Have low-trust, low-connectivity, low resource level VM for untrusted work.

no-dr-onboard 4y ago

You might have it backwards. Most people typically do untrusted actions inside the VM and keep their host “clean”. You’re correct though that VM escapes are pretty difficult, especially with modern, patched microcode processors.

a1xndr 4y ago
> VM escapes are pretty difficult, especially with modern, patched microcode processors Most VM escapes happen through buggy virtual-devices written in C/C++/.. code. Virtual-device bugs that are exploitable by attackers with root access in the VM are found frequently.
- fsflover 4y ago
  It's not frequent at all with Qubes hardware virtualization: https://www.qubes-os.org/security/xsa/ https://www.qubes-os.org/security/xsa/.
danuker 4y ago
> modern, patched microcode processors This makes me wonder how many security holes CPUs have which have been buried into secrecy by the manufacturers.

fsflover 4y ago

You are right. The host on Qubes OS (dom0) has no networking and never runs any software by default. Also, hardware virtualization which Qubes uses last time was broken in 2006 by its founder: https://en.wikipedia.org/wiki/Blue_Pill_(software) https://en.wikipedia.org/wiki/Blue_Pill_(software).

jeroenhd 4y ago
The hypervisor problem can be solved (in theory) with secure boot configured with custom keys and full disk encryption. I don't know anyone who actually uses Qubes so I don't know how practical that solution is. Coreboot has something similar to secure boot, so even if you use an open source boot loader, this can be done. An attacker would need to do some quite invasive hardware tampering to get a third party hypervisor to work on a system secured like that. Furthermore, preventing hypervisor detection requires constant updates if the OS itself is configured to check for the presence of a hypervisor. There's a constant arms race going on between security researchers and cybercriminals who don't want their malware to trigger on analysts' machines, many of which use virtualization to easily reset the system back to a known, secure state. Every time malware comes up with a new method of detection your evil hypervisor needs to be patched to fake that stuff too or you risk detection next time the OS updates its detection algorithms.
- fsflover 4y ago
  This should work with Qubes quite well: https://puri.sm/posts/pureboot-101-first-boot-first-update-and-detecting-software-tampering/ https://puri.sm/posts/pureboot-101-first-boot-first-update-a... See also: https://forum.qubes-os.org/t/verified-boot-on-qubes-a-lofty-dream/2524 https://forum.qubes-os.org/t/verified-boot-on-qubes-a-lofty-...
LanternLight83 4y ago
I just wish Qubes had a simpler architecture, such that dom0 and the Qubes Components could be implemented in eg. Guix or Nix instead of a traditional distro. Love Qubes' desktop integrations.