3

Below is a copy of my answer that I gave in some other thread (Would running VMs inside of VMs be a more secure way to study viruses, etc?) about a topic of security of nested virtualization. I would like to know whether my answer was right of wrong. I'd like to know whether paravirtualized drivers are actually a security risk and whether SELinux (as sVirt) can do anything about it.

Me: (this was in mid-2012, before good support for nested virtualization)

You can run VM inside a VM, but you probably won't be able to use hardware virtualization. It should still work thought, but you will probably have to use different hypervisors (example: VirtualBox for first VM, VMware for second). I think this is unnecessary and insecure. RHEL and Fedora (and maybe others) have built-in support for running KVM and using SElinux to restrict the VM process on the host. SElinux provides ample protection, but not against paravirtualized driver vulnerabilities. For maximum security, do not use paravirtualized drivers.

X:

not in citation given - nothing I could find suggests that SELinux is ineffective when paravirtualized drivers are in use on KVM, and a quick Google search didn't turn up anything either. Do you have a source for this?

More than 2 years have passed

Me:

I think the last part was my own idea and there is no other source. IMO, paravirtualized drivers are not subject to SELinux security controls because SELinux controls userspace processes, files, etc. I think paravirtualized drivers work by direct communication between guest kernel and hypervisor, which results in superior performance, but expose a part of hypervisor to the guest, that would otherwise be unreachable. I have no evidence for this, so I could be completely wrong.

Improve this question
0

1 Answer 1

Reset to default
3

Paravirtualized drivers will be a security risk only if the paravirtualization interface is designed in a way to leak hypervisor state or information to the guest. it is no more secure or insecure than having system calls in an OS or having applications talking to device drivers. If you think about it, guest talking to a hypervisor is similar to an application talking to the kernel. The more entry points you add into the hypervisor, the larger your attack surface and the less secure.

Improve this answer
2
  • Is this answer still up-to-date after all these disastrous CPU vulnerabilities that have been found since?
    – Teekin
    Commented Apr 13, 2020 at 16:46
  • I believe the answer still applies, and perhaps even more so now, given the CPU vulnerabilities. When you are writing hypervisor code, now, you need to also account for the fact that a paravirtualized driver or guest has another means to attack the interface, i.e through micro-architectural side channels.
    – Raghu
    Commented Apr 14, 2020 at 17:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .