5 ms·

If for some reason using QEMU with potentially hostile code (not recommended!), disable all the hardware emulation you can!

by j_s 10y ago

rwmj 10y ago
You should keep qemu up to date of course, and remove devices you don't need. But more importantly ensure you are using it through libvirt. Libvirt adds an SELinux or AppArmor layer, and a container, and enables seccomp for the qemu process. So even if the qemu process is compromised, it is very limited in what it can do to the host.
- sdeziel 10y ago
  Unfortunately on Ubuntu, seccomp is opt-in only. Works well when enabled though.
- aseipp 10y ago
  FWIW I've never really been impressed with QEMU's seccomp sandboxing, because it's almost entirely bolted on, and in the grand scheme, I think, does little. Does libvirt do anything substantially different or just "turn it on"? If you look at the list of syscalls whitelisted[1], it's almost a joke -- you could literally do just about anything given those syscalls if you actually had code execution... And every one of those syscalls is a direct interface to the kernel, which becomes the weakest link in a container/LSM environment where your code will be running, presumably. How is seccomp going to stop my exploit when almost everything my exploit could ever need is whitelisted, including hundreds of syscalls that directly talk to the kernel? I'm glad QEMU is improving their security footprint, but I honestly think its seccomp support is way overblown even though people like to bring it up... When your seccomp policy looks like the one from QEMU -- it just bans a few things they've never used, rather than only allowing things they should use. Taking advantage of it to the level of something like Chrome does (which truly mitigates attack surface with process isolation) would require almost an entire redesign of the whole thing, I think. [1] https://github.com/qemu/qemu/blob/master/qemu-seccomp.c https://github.com/qemu/qemu/blob/master/qemu-seccomp.c
  - rwmj 10y ago
    Sure, I agree. It's the SELinux policy which really confines QEMU. For example the compromised QEMU will only be able to open exactly the files containing the guest's drives (not even the drives of other guests on the same host).
    - secur101 10y ago
      @rwmj can you please point to the list of white-listed QEMU-KVM devices used in RHEL?
      - rwmj 10y ago
        The qemu source RPMs are now hosted here: https://git.centos.org/project/rpms https://git.centos.org/project/rpms You have to type "qemu" in the box at top right. The qemu-kvm-rhev source RPM is here: http://ftp.redhat.com/pub/redhat/linux/enterprise/7Server/en/RHEV/SRPMS/ http://ftp.redhat.com/pub/redhat/linux/enterprise/7Server/en...
        secur101 10y ago
        Thanks for your reply. I made some suggestions for KVM and QEMU below. Also I was wondering what your POV is on my thoughts: https://news.ycombinator.com/item?id=14227605 https://news.ycombinator.com/item?id=14227605 https://news.ycombinator.com/item?id=14228563 https://news.ycombinator.com/item?id=14228563
bonzini 10y ago
Pretty much all cloud providers that use KVM (where "pretty much all" probably means all except Google) are using QEMU and potentially can be running hostile code, so the "not recommended" remark is perhaps a bit exaggerated.
- 0xFFC 10y ago
  What do they use at Google?
  - rwmj 10y ago
    Some proprietary code replacing qemu (but still using KVM). Since they still have to emulate PC devices, this just means they have a different set of security holes and fewer people reviewing the code.
    - sitkack 10y ago
      Given QEMUs track record, I'd wager that the goog code gets more reviewers and more testing. QEMU is literally swiss cheese, or it emulates real swiss cheese, poorly.
      - bonzini 10y ago
        Any proof of what you are saying, or is it just FUD? Most QEMU CVEs are related to devices that should never be used in cloud provider scenarios (you'll often find that they are disabled in RHEL for this exact reason). If anything, prompt handling of vulnerabilities in those devices is a sign of taking security seriously...
        j_s 10y ago
        Not sure about OP; it is more of an appeal to authority here: https://news.ycombinator.com/item?id=13484146 https://news.ycombinator.com/item?id=13484146 No doubt in my mind Google has the top-tier working on this, at least now that GCE is public-facing. I was impressed to read they actively monitor/mitigate Rowhammer, something I've not seen mentioned anywhere else (could just be my ignorance).

If for some reason using QEMU with potentially hostile code (not recommended!), disable all the hardware emulation you can!

by j_s 10y ago

If for some reason using QEMU with potentially hostile code (not recommended!), disable all the hardware emulation you can!

rwmj 10y ago

You should keep qemu up to date of course, and remove devices you don't need. But more importantly ensure you are using it through libvirt. Libvirt adds an SELinux or AppArmor layer, and a container, and enables seccomp for the qemu process. So even if the qemu process is compromised, it is very limited in what it can do to the host.

sdeziel 10y ago
Unfortunately on Ubuntu, seccomp is opt-in only. Works well when enabled though.
aseipp 10y ago
FWIW I've never really been impressed with QEMU's seccomp sandboxing, because it's almost entirely bolted on, and in the grand scheme, I think, does little. Does libvirt do anything substantially different or just "turn it on"? If you look at the list of syscalls whitelisted[1], it's almost a joke -- you could literally do just about anything given those syscalls if you actually had code execution... And every one of those syscalls is a direct interface to the kernel, which becomes the weakest link in a container/LSM environment where your code will be running, presumably. How is seccomp going to stop my exploit when almost everything my exploit could ever need is whitelisted, including hundreds of syscalls that directly talk to the kernel? I'm glad QEMU is improving their security footprint, but I honestly think its seccomp support is way overblown even though people like to bring it up... When your seccomp policy looks like the one from QEMU -- it just bans a few things they've never used, rather than only allowing things they should use. Taking advantage of it to the level of something like Chrome does (which truly mitigates attack surface with process isolation) would require almost an entire redesign of the whole thing, I think. [1] https://github.com/qemu/qemu/blob/master/qemu-seccomp.c https://github.com/qemu/qemu/blob/master/qemu-seccomp.c
- rwmj 10y ago
  Sure, I agree. It's the SELinux policy which really confines QEMU. For example the compromised QEMU will only be able to open exactly the files containing the guest's drives (not even the drives of other guests on the same host).
  - secur101 10y ago
    @rwmj can you please point to the list of white-listed QEMU-KVM devices used in RHEL?
    - rwmj 10y ago
      The qemu source RPMs are now hosted here: https://git.centos.org/project/rpms https://git.centos.org/project/rpms You have to type "qemu" in the box at top right. The qemu-kvm-rhev source RPM is here: http://ftp.redhat.com/pub/redhat/linux/enterprise/7Server/en/RHEV/SRPMS/ http://ftp.redhat.com/pub/redhat/linux/enterprise/7Server/en...
      - secur101 10y ago
        Thanks for your reply. I made some suggestions for KVM and QEMU below. Also I was wondering what your POV is on my thoughts: https://news.ycombinator.com/item?id=14227605 https://news.ycombinator.com/item?id=14227605 https://news.ycombinator.com/item?id=14228563 https://news.ycombinator.com/item?id=14228563

bonzini 10y ago

Pretty much all cloud providers that use KVM (where "pretty much all" probably means all except Google) are using QEMU and potentially can be running hostile code, so the "not recommended" remark is perhaps a bit exaggerated.

0xFFC 10y ago
What do they use at Google?
- rwmj 10y ago
  Some proprietary code replacing qemu (but still using KVM). Since they still have to emulate PC devices, this just means they have a different set of security holes and fewer people reviewing the code.
  - sitkack 10y ago
    Given QEMUs track record, I'd wager that the goog code gets more reviewers and more testing. QEMU is literally swiss cheese, or it emulates real swiss cheese, poorly.
    - bonzini 10y ago
      Any proof of what you are saying, or is it just FUD? Most QEMU CVEs are related to devices that should never be used in cloud provider scenarios (you'll often find that they are disabled in RHEL for this exact reason). If anything, prompt handling of vulnerabilities in those devices is a sign of taking security seriously...
      - j_s 10y ago
        Not sure about OP; it is more of an appeal to authority here: https://news.ycombinator.com/item?id=13484146 https://news.ycombinator.com/item?id=13484146 No doubt in my mind Google has the top-tier working on this, at least now that GCE is public-facing. I was impressed to read they actively monitor/mitigate Rowhammer, something I've not seen mentioned anywhere else (could just be my ignorance).