Thats a good question, and there are a few angles to the answer. The most significant one is we don't need to: unlike say Nova, which receives untrusted image and needs to modify them (at least until we finish deprecating and deleting file-injection in favour of [deployment chosen] (metadata||configdrive)), diskimage-builder is run by the user to create their image, and is being used to create their production environment. We use HTTPS to retrieve the vendor image checksums, and check the checksum on the image before we do anything with it - if the vendor image is corrupted, the attacker could equally just corrupt the vendor kernel, and backdoor their entire production infrastructure. Then, we build a fresh filesystem, so the only thing we do with the filesystem bits we receive is copy data out of them. You are right that there is a narrow attack vector there, [but see above]; we could use guestfs's fuse support to mount and copy out the data that way. As the delivery of the initial upstream image is amortised over potentially many image creations, I would be quite happy to tolerate some minor extra overhead there. As far as using guestfs later in the build process - I don't see any need for that; we start with a tarball, we chroot into that, we make a filesystem matching the size of the content and rsync the contents over. The reason we start a new filesystem is that its faster: we started initially by cloning the original disk image and modifying, but it turns out that vendor images have wildly varying filesytem sizes and definitions, and we needed to provide images with well understood and documentable characteristics. Resizing ext* filesystems up and down isn't the fastest process, particularly on LTS style releases like Ubuntu LTS and RHEL. So this is in no way a reflection on guestfs, more on the problem domain we're working on. That said, there is repeated mild interest in having diskimage-builder available via an API : I think the simple image building service some Red Hatters have been working on with Oz and Nova VM's is a great model here: we can have a API owned image that contains diskimage-builder ready to run - perhaps with common vendor images already present in it/stored on a volume we can attach a thin clone of - and run diskimage-builder within that VM, once. If the user requested base image, or the user supplied scripts are hostile, thats fine: the image building VM would be discarded at the end and the user just gets back their own bad image. -Rob Robert Collins <rbtcollins@xxxxxx> Distinguished Technologist HP Cloud Services ________________________________________ From: Richard W.M. Jones [rjones@xxxxxxxxxx] Sent: Thursday, 27 June 2013 23:25 To: Fedora Cloud SIG Cc: Collins, Robert (HPCS) Subject: Re: Should Fedora revisit the idea having "one " image to be used across the cloud providers? On Wed, Jun 26, 2013 at 07:23:44PM +0000, Collins, Robert (HPCS) wrote: > Hi, I'm the project lead for TripleO (OpenStack on OpenStack - a > disk image based approach to deploying and maintaining OpenStack > clouds), and we have a tool 'diskimage-builder' which consumes > upstream vendor cloud images and customises them. Why don't you use libguestfs for this? I see you have a list of "safe" disk images, but still .. using losetup and mount to mount disk images that you download from the net on your host kernel is very dangerous. A rogue filesystem which exploits a fsdriver bug bypasses all permissions checks, process boundaries, SELinux, and the usual things that we use to keep VMs safe. Plus libguestfs has a much cleaner API for modifying disk images, has a Python API[1] and it's already being used elsewhere in OpenStack. Rich. [1] http://libguestfs.org/guestfs-python.3.html -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud
