| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Xen 3.4.1 and QCOW - sparse backing file support gone fo
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
|
|
|
| |
|
Home