5 ms·

Yet another example where SELinux could have mitigated this effect.

• rwmj 10y ago
  Anyone using qemu has disabled 9p for a really long time.
  • chrisper 10y ago
    How do I disable it or is it disabled by default?
    • bonzini 10y ago
      It is a device that you have to add explicitly to the virtual machine.
  • bonzini 10y ago
    No one using qemu in production with untrusted VMs should be using 9pfs, but does anyone except RHEL/CentOS actually leave it out of the binary?
• theamk 10y ago
  Maybe? I am not convinced. I have used qemu (with virtfs) in my interactive session to test possibly suspicious 3-rd party apps, running as my regular interactive user. With this vulnerability, the app might have escaped the sandbox and added evil stuff to my .bashrc. The SELinux would be totally useless there. In other circumstances, the damage would be much more localized -- I mean, if you run qemu as daemon, you are likely doing it as non-privileged user anyway, so even regular unix permissions would be effective.
• ajross 10y ago
  Strictly, that's not true. The exploit here is access to the filesystem environment of the host process from the guest. That happens entirely within the Qemu process and is invisible to SELinux. What you're saying, I think, is that the SELinux could have been used to encapsulate the host process from the rest of the system. Which is true, but sort of specious. Traditional unix security paradigms (e.g. run every guest instance in its own UID, whatever) would have worked fine to mitigate the damage too.
  • vbernat 10y ago
    I think you are mistaken. Anything syscall-related is seen by SELinux which may accept or deny the request. Checking file access is one of the major use of SELinux. libvirt comes with the appropriate integration with SELinux (and Apparmor) to ensure that a QEMU process won't be able to read or write a file it shouldn't (and to avoid spawning process, transitioning state or poking into the memory or disk of a neighbor QEMU). SELinux/Apparmor defeat most of the latest vulnerabilities in QEMU.
    • ajross 10y ago
      You're talking about SELinux within the guest then? The exploit requires kernel execution, so it's not relevant. Anyone capable of running this would be capable of evading LSM hooks by definition. Outside the guest, sure, you could use SELinux to firewall VMs from access to anything more than a minimal filesystem. But you could use any of a zillion other techniques too. It's a specious point not relevant to this exploit, which certainly cannot have been prevented by SELinux.
      • vbernat 10y ago
        I am talking on SELinux in the host which would totally prevent this exploit as SELinux would not allow you to browse the host. You seem to say that nobody does that. libvirt uses SELinux out of the box to do exactly that.
        • ajross 10y ago
          You're talking past me and missing the point then. SELinux would absolutely not prevent this exploit: it allows the guest access to the filesystem seen by the host process, full stop. You're talking about deployment policy[1] that might help to mitigate VM exposure. And that's a fine idea. But it's not equivalent to saying that SELinux could have prevented this, and saying so in a security context is misleading users. [1] Which has to be developed, after all. Simply saying you're "using SELinux" does nothing to prove to me you have no vulnerabilities or mistakes in your rule set.