Re: [Qemu-devel] [PATCH 4/4][RFC] Add logic to QEMU to read command line options from qcow2 images

[Daniel P. Berrange]

On Thu, Aug 09, 2007 at 09:54:17AM -0500, Anthony Liguori wrote:
> Daniel P. Berrange wrote:
> >On Wed, Aug 08, 2007 at 04:52:58PM -0300, Jorge Luc?ngeli Obes wrote:
> >  
> >>This patch makes QEMU check for command line options stored in qcow2 
> >>images.
> >>    
> >
> >I think it is a bad idea from a security POV to automatically extract & 
> >use command line args from  a disk image like this without the admin 
> >explicitly requesting this capability. 
> >
> >eg If I grabbed a demo disk image from a vendors' or community website I 
> >would
> >certainly not trust whatever args may happen to be embedded in the disk 
> >image
> >and thus do not want QEMU to be automatically running using them.
> >
> >I'd recommend having some command line flag to turn this capability on. For
> >example a '--args PATH-TO-DISK' flag,
> >
> >  qemu --args $HOME/fedora.qcow
> >  
> 
> That's pretty nasty.  How do you specify which disk this is then?  I do 

Well that's the same problem you have with the current patch - it just assumes
you have a single disk & its going to be hda.

> agree with you that allowing arbitrary command line arguments in an 
> image file is probably a bad idea.  I think the general idea of being 
> able to launch a single image is useful but I suspect this is not the 
> right way to do it.
> 
> What are some people thinking would want to be stored in the file?  Most 
> of the command line options are more host specific than guest specific I 
> think.  Maybe we can store a pseudo-config instead that only contains a 
> subset of parameters (and therefore, wouldn't pose a security risk)?

Yeah that's a much more open ended & interesting problem to address. I
personally wouldn't store command line arguments in the image at all.
I think we'd be better off providing a generic metadata  description of
the capabilities / requirements of the guest OS/kernel inside the image.
So any virtualization platform could read the metadata, determine whether
the guest is supported & then boot it with appropriate commands. 

Once you have a good metadata description, there's many options for how you
distribute it - in the qcow image, or in tar.gz containing the image, the 
metdata & any other relevant bits. We've been trying to prototype a sample
metdata description &  a virt-image tool for launching an image based on
its metadata using libvirt.

   http://people.redhat.com/dlutter/virt-image/

The same metadata could be used to build a qemu command line directly for
the non-libvirt usage cases.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|