If you are using SELinux and libvirtd, the sVirt integration between the two automatically keeps one vm from attacking another vm should there be a way to compromise the host kernel.
If the host kernel is compromised (where I assume SELinux is running in this scenario) wouldn't that render SELinux itself suspect. It seems like SELinux's integrity must be dependent on that of its own kernel, or have I misunderstood the scenario you describe ?
There have been at least a few kernel privesc vulnerabilities, for example, which have apparently been mitigated successfully with SELinux (I assume that the SELinux policies prevent the necessary pre-conditions of the exploit being met, like denying certain ioctls etc. before they can do damage). I guess it depends on the nature of the exploit.
In any case it sounds like libvirtd can automatically assign a unique category to each VM guest's resources in a way which inhibits guest-to-guest interactions by default.
No you understood it correctly. There are several kernel exploits that involve things like sending nasty ioctls, opening raw devices, reading/writing to /dev/mem, etc that SELinux will mitigate when it is enforcing mode. It is not a catch-all by any means, but defense in-depth involves multiple layers. SELinux has demonstrably prevented local privilege escalation 0days from working.
