> Deployment of patches or mitigations is NOT permitted (except on
systems used and administered only by organisations which are members
of the Xen Project Security Issues Predisclosure List). Specifically,
deployment on public cloud systems is NOT permitted.
Presumably it's because public deployment would have been noticed by malicious actors, who would have reverse engineered the fix and tried to use the exploit elsewhere.
I'm guessing that the embargo has run out and it's no longer restricted.
Perhaps its possible to pick up on the change from inside the Guest VM, and patching the problem on a public cloud would potentially expose the issue before members of the "Xen project Security Issues Predispose list" had a chance to patch? I'm not sure.
XEN embargoes patches to make sure they are released as synchronous as possible (i.e. patches hit the major distros and are deployed to all major deployments at the same time). The additional restriction in this case suggests that they think that observing a patched system as customer allows to figure out details of the vulnerability.
> The decision not to permit deployment was made by the group that, at their discretion, disclosed the issue to the Xen Project Security Team.
Xen has, in the past, worked with major cloud service providers to get patches deployed early. Perhaps the view was that the major cloud providers aren't enabling cdrom to begin with, or are using stubdomains, so it wasn't worth risking the broader exposure; or perhaps there were past incidents with early disclosure by cloud providers.
Note that it says "by the group that disclosed the issue". Xen's security process says that it's the people who disclose issues to xen-security that get to make this decision about pre-deployment.
Agree. There have been several vulns in the fringes of QEMU device emulation code before but typically in lesser used devices (floppy etc). OTOH it's very common to use CDROM emulation to install systems and I'm sure there are plenty of admins who leave the ISO exposed to the guest "just in case".
Note that without a separate Linux privilege escalation exploit, running QEMU in a least-privilege "container" for each VM should help stem the bleeding.
If you bother to read the second link I posted, you'll see that cgroups does both (some) isolation and resource management. It's a layered scheme however and you absolutely should be using SELinux which is where the really comprehensive confinement happens.
You can flat out wrong about this, as you have been in your other answers. I am an upstream libvirt committer so I do know a fair bit about what libvirt can do. The fact is that the isolation of cgroups will prevent various denial of service bugs, and also access to non-whitelisted devices.
It is nowhere near as comprehensive as SELinux isolation, as I clearly said way up there in my initial response -- which is also the reason why when you use Docker on RHEL, most of the security comes from the additional SELinux protections Red Hat have added.
I agree with you that cgroups protect against denial of service attacks, and that the device whitelist provides some additional security (I actually did not know about the latter, so thanks! TIL). Thinking about it, if you exclusively use block devices for storage, this is a lot better than I expected.
But still, this is nowhere from a "a least-privilege container for each VM" as you suggested.
(I'm a heavy libvirt user myself - thank you for your work on it!)
XenServer runs their version of qemu under a unique unused uid, in a empty chroot and with a separate network namespace. This is the default behavior under XenServer.
24 comments
[ 3.1 ms ] story [ 68.4 ms ] threadWhat is the rationale for this?
I'm guessing that the embargo has run out and it's no longer restricted.
Xen has, in the past, worked with major cloud service providers to get patches deployed early. Perhaps the view was that the major cloud providers aren't enabling cdrom to begin with, or are using stubdomains, so it wasn't worth risking the broader exposure; or perhaps there were past incidents with early disclosure by cloud providers.
Does it? Afaik libvirt requires AppArmor/SELinux for this.
It is nowhere near as comprehensive as SELinux isolation, as I clearly said way up there in my initial response -- which is also the reason why when you use Docker on RHEL, most of the security comes from the additional SELinux protections Red Hat have added.
But still, this is nowhere from a "a least-privilege container for each VM" as you suggested.
(I'm a heavy libvirt user myself - thank you for your work on it!)