openstack team mailing list archive

[Scott Moser <smoser@xxxxxxxxxx>]

On Wed, 8 Aug 2012, Michael Still wrote:

> On 08/08/12 07:38, 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.
>
> I am in the process of re-writing the config drive code as we speak. The
> re-write supports (and defaults to) providing the config drive as an
> iso9660 image.
>
> There are two places that mounting occurs with the new code:
>
>  - if the user wants a vfat config drive, as I couldn't find a way to
> create a vfat filesystem from a directory using userspace code. This
> should be "relatively safe" though because the filesystem which is
> mounted is created by the code just before the mount. [1]

For sufficiently archaic filesystems, there are user-space tools that
understand how to manipulate them.  vfat has reached such a state.
mtools can read and write vfat filesystem without any help from the
kernel.

Heres an example of how to use it as I've been confused by the
documentation before.

 # get a directory to copy
 $ wget https://launchpad.net/python-novaclient/trunk/2.6.10/+download/python-novaclient-2.6.10.tar.gz
 $ tar -xvzf python-novaclient-2.6.10.tar.gz
 $ dir=python-novaclient-2.6.10

 # create a 64M file and put vfat filesystem on it
 $ img="my-vfat.img"
 $ rm -f $img;
 $ truncate --size 64M $img;
 $ mkfs.vfat -n MY-LABEL $img

 # copy contents to image and then off that to a new dir
 $ mcopy -ospmi $img $dir/* ::
 $ mcopy -ospmi $img :: $dir.new
 $ du -hs $dir.new $dir
 736K  python-novaclient-2.6.10.new
 736K  python-novaclient-2.6.10
 $ diff -Naur $dir $dir.new && echo "the same"
 the same

Outside of the dependency on mtools, this seems like a much better
solution for limited vfat filesystem writing than libguestfs or kernel
mount.

I carried this example on to actually boot a kvm with my-vfat.img
attached and mounted it and it looked good there also.  the only issue I
saw in this was the timestamp on the directory
python-novaclient-2.6.10.new.

>  - if the user specifies an image from glance for the injection to occur
> to. This is almost certainly functionality that you're not going to like
> for the reasons stated above. Its there because v1 did it, and I'm

Either you or I are reading the existing nova/virt/libvirt/driver.py
'config_drive_id' code incorrectly.  That code and
nova/compute/api.py:_create_instance seem to me to indicate if
config_drive_id is true than config_drive is not true.

the mount and add path is only taken if config_drive is true.


> willing to remove it if there is a consensus that's the right thing to
> do. However, file IO on this image mount is done as the nova user, not
> root, so that's a tiny bit safer (I hope).
>
> https://review.openstack.org/#/c/10934/

As I've said in the review, I think this function should not exist in
config-drive-v2.

I do think that "attach volume by volume id at boot" function should be
added to nova (it may already be), but it has no relevance to
config-drive.

Scott