Skip to main content
added 1721 characters in body
Source Link
Matrix
  • 4.1k
  • 17
  • 26

This questionBelow is regardinga copy of my answer that I gave in some other thread http://security.stackexchange.com/a/16969/11001, especially(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 latest commentanswer was right of wrong. I'd like to know the truthwhether paravirtualized drivers are actually a security risk and whether SELinux (as sVirt) can do anything about thisit.

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.

This question is regarding my answer in http://security.stackexchange.com/a/16969/11001, especially my latest comment. I'd like to know the truth about this.

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.

Source Link
Matrix
  • 4.1k
  • 17
  • 26

Are paravirtualized drivers a security risk?

This question is regarding my answer in http://security.stackexchange.com/a/16969/11001, especially my latest comment. I'd like to know the truth about this.