WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Xen 3.4.1 and QCOW - sparse backing file support gone fo

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Xen 3.4.1 and QCOW - sparse backing file support gone forever?
From: Martin Troester <TroyMcClure@xxxxxx>
Date: Fri, 25 Sep 2009 23:05:48 +0200
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Fri, 25 Sep 2009 14:11:14 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <19132.52745.738000.235297@xxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4ABBD9DE.5090103@xxxxxx> <19132.52745.738000.235297@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.23 (X11/20090817)
Ian,

thanks for giving me some details on a possible change for Xen 3.5.

Ian Jackson wrote:
Martin Troester writes ("[Xen-devel] Xen 3.4.1 and QCOW - sparse backing file 
support gone forever?"):
If that's not in, is there any plan how to deal with scenarios like
mine? Especially, is there way to convert my images to some usable
format for not having to stick to Xen 3.2.1? Or is it just too exotic so
that I throw everything away and think of something else? (I am still
thinking that stacking qcow images is not the most stupid thing to do...)

If it works for you then your system may have a security problem.  I
haven't analysed this use case in detail and it would depend on the
exact structure of your storage.
I think I am still missing the point on the severity of this attack.

Assuming I offer a user a virtual machine with a qcow2 image backed by another qcow2 image which is ultimately backed by a raw image, how would a user ever get the possibility to modify the first part of the raw image to resemble a qcow header? This seems to be the point where I have problems following your scenario. From my understanding, the user would always do modifications on the upper layer of the stack of files, only reading from below, writing to "his" proper layer. If that was not the case, he would be able to compromise other layer's data, even without the qcow header vs. raw story, right?

So, how would a user ever get the possibility to write the raw part? Only other option I can think of is giving the user access to the files themselves (e.g. via a user account in Dom0, or any other means of file access to that container), but that would be a security issue by itself, even without the whole header discussion, wouldn't it?

I hope I'm not making a fool of myself here, but I thought I'd put my thoughts here to understand where I'm missing the point. If this does not belong to this list, I'd be happy to get your answer via private mail.

Thanks for some more hints on this issue!

Kind Regards,
Martin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>