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

[Martin Troester <TroyMcClure@xxxxxx>]

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