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(a)hp.com>
Distinguished Technologist
HP Cloud Services
________________________________________
From: Richard W.M. Jones [rjones(a)redhat.com]
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