Hacker Neue

Preferences
vbernat parent
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
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 OP
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
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.

vbernat OP
Title says "virtfs permits guest to access entire host filesystem". First answer says "Yet another example where SELinux could have mitigated this effect". You say "That's not true".

"Entire host filesystem" is "/" and anything below, right? If your QEMU process is running in a SELinux context, there is no way it could access the "entire host filesystem".

And as your footnote, a mistake in SELinux configuration is highly unlikely. Once your process is running in a context, you have to have an explicit transition to the unconfined context or you have to relabel the "entire host filesystem" with the context of the QEMU process.

This item has no comments currently.