On Tue, 2012-08-07 at 17:38 -0400, Eric Windisch wrote: > > Pádraig Brady from Red Hat discovered that the fix implemented for > > CVE-2012-3361 (OSSA-2012-008) was not covering all attack scenarios. By > > crafting a malicious image with root-readable-only symlinks and > > requesting a server based on it, an authenticated user could still > > corrupt arbitrary files (all setups affected) or inject arbitrary files > > (Essex and later setups with OpenStack API enabled and a libvirt-based > > hypervisor) on the host filesystem, potentially resulting in full > > compromise of that compute node. > > > > Unfortunately, this won't be the end of vulnerabilities coming from > this "feature". > > Even if all the edge-cases around safely writing files are handled (and > I'm not sure they are), simply mounting a filesystem is a very > dangerous operation for the host. > > The idea had been suggested early-on to supporting ISO9660 filesystems > created with mkisofs, which can be created in userspace, are read-only, > and fairly safe to produce, even as root on compute host. > > That idea was apparently shot-down because, "the people who > documented/requested the blueprint requested a read-write filesystem > that you cannot obtain with ISO9660". Now, everyone has to live with a > serious technical blunder.
Why do we ever read a filesystem touched by a guest in the host? I think the first step is to make sure that a filesystem that the guest touched never gets used by the host again, not doing so is just way to much of a security risk. Second there are lots of options to create filesystem entirely in userspace with contents that can later be written to: - mformat for vfat - growisofs or others for udf - genext2fs for ext2 - e2tools to copy files into an ext2/ext3 filesystem previously created by mke2fs Especially udf is a very interesting options as just about any modern operating system supports it. The same is true for vfat, but vfat is fairly limiting for many use cases. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
