All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Troester <TroyMcClure@web.de>
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: Xen 3.4.1 and QCOW - sparse backing file support gone	forever?
Date: Fri, 25 Sep 2009 23:05:48 +0200	[thread overview]
Message-ID: <4ABD30AC.9050109@web.de> (raw)
In-Reply-To: <19132.52745.738000.235297@mariner.uk.xensource.com>

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

  reply	other threads:[~2009-09-25 21:05 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-24 20:43 Xen 3.4.1 and QCOW - sparse backing file support gone forever? Martin Troester
2009-09-25 14:04 ` Ian Jackson
2009-09-25 21:05   ` Martin Troester [this message]
2009-10-05 10:05     ` Ian Jackson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ABD30AC.9050109@web.de \
    --to=troymcclure@web.de \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.