6 ms·

Is there significant risk in booting untrusted OS images within Qemu?

by jai_ 8y ago

AnthonBerg 8y ago
It is unknown. It might be unknowable.
- AnthonBerg 8y ago
  Due to a couple downvotes I want to explain by way of a question: Can it to your knowledge be proven that QEMU is fully secure? Given that bugs which have been found in it previously have been fixed, can we know from now on that it’s 100% safe? As far as I know there does not exist a way of rigorously proving that. fwiw my interest in theoretical computers and formal verification based on this fundamental aspect.
rwmj 8y ago
You need to take steps to harden qemu - I wouldn't do it with qemu out of the box using the command line. In RHEL (eg for Red Hat's OpenStack) we do: * Aggressively compile out unused features/devices. * Confine each VM with separate SELinux contexts (sVirt). * Run qemu as a special non-root user. * Use seccomp to confine the system calls. * Pass in pre-opened file descriptors to qemu, so qemu doesn't need to open files (helps with writing tightly confined SELinux policy). * Run qemu in a cgroup. * Run qemu-img with resource limits. * Compile qemu with all hardening features enabled like RELRO, PIE, etc. * Audit the code manually and with Coverity. * Take security reports seriously and have a fast patching mechanism (you can effectively "live patch" qemu by migrating a VM off the old qemu and on to the new qemu). Probably more that I've forgotten about ...
- rbanffy 8y ago
  This sounds like a lot of fun. What are you doing with those VMs?
  - rwmj 8y ago
    I work for Red Hat and this is how VMs are configured by default if you buy RHV, RHOSP, KubeVirt or similar on-prem or public virtualization or cloud products from us. You can turn some of these mitigations off if you want, although I wouldn't personally recommend it - at some time of another there has been a security critical bug which has been mitigated by each one of these changes. Some of our customers are running untrusted VMs in their public clouds using this configuration. Others will be running on-premises virtualization set ups with VMs from across their companies which can be equally risky. SELinux is probably the most important mitigation in the list, and while it has a bad reputation that's mostly from people who haven't used it for over a decade. I have SELinux enforcing on every machine I use, and it rarely causes an issue.
- nerpderp82 8y ago
  Please make a gist or blog post!
syn0byte 8y ago
Short Answer: Yes. Historic(2015) VM escape example https://venom.crowdstrike.com/ https://venom.crowdstrike.com/ I doubt anyone is wasting a good zero-day on disposable qemu netboot images. Someone may try a venom(like) image for 'fun'.

Is there significant risk in booting untrusted OS images within Qemu?

by jai_ 8y ago

Is there significant risk in booting untrusted OS images within Qemu?

AnthonBerg 8y ago

It is unknown. It might be unknowable.

AnthonBerg 8y ago
Due to a couple downvotes I want to explain by way of a question: Can it to your knowledge be proven that QEMU is fully secure? Given that bugs which have been found in it previously have been fixed, can we know from now on that it’s 100% safe? As far as I know there does not exist a way of rigorously proving that. fwiw my interest in theoretical computers and formal verification based on this fundamental aspect.

rwmj 8y ago

You need to take steps to harden qemu - I wouldn't do it with qemu out of the box using the command line. In RHEL (eg for Red Hat's OpenStack) we do: * Aggressively compile out unused features/devices. * Confine each VM with separate SELinux contexts (sVirt). * Run qemu as a special non-root user. * Use seccomp to confine the system calls. * Pass in pre-opened file descriptors to qemu, so qemu doesn't need to open files (helps with writing tightly confined SELinux policy). * Run qemu in a cgroup. * Run qemu-img with resource limits. * Compile qemu with all hardening features enabled like RELRO, PIE, etc. * Audit the code manually and with Coverity. * Take security reports seriously and have a fast patching mechanism (you can effectively "live patch" qemu by migrating a VM off the old qemu and on to the new qemu). Probably more that I've forgotten about ...

rbanffy 8y ago
This sounds like a lot of fun. What are you doing with those VMs?
- rwmj 8y ago
  I work for Red Hat and this is how VMs are configured by default if you buy RHV, RHOSP, KubeVirt or similar on-prem or public virtualization or cloud products from us. You can turn some of these mitigations off if you want, although I wouldn't personally recommend it - at some time of another there has been a security critical bug which has been mitigated by each one of these changes. Some of our customers are running untrusted VMs in their public clouds using this configuration. Others will be running on-premises virtualization set ups with VMs from across their companies which can be equally risky. SELinux is probably the most important mitigation in the list, and while it has a bad reputation that's mostly from people who haven't used it for over a decade. I have SELinux enforcing on every machine I use, and it rarely causes an issue.
nerpderp82 8y ago
Please make a gist or blog post!

syn0byte 8y ago

Short Answer: Yes. Historic(2015) VM escape example https://venom.crowdstrike.com/ https://venom.crowdstrike.com/ I doubt anyone is wasting a good zero-day on disposable qemu netboot images. Someone may try a venom(like) image for 'fun'.