Re: [Qemu-devel] [PATCH 0/3] vpc: support probing of fixed size images

[Kevin Wolf <kwolf@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2352 bytes --]

Am 15.08.2014 um 16:00 hat Eric Blake geschrieben:
> On 08/15/2014 07:37 AM, Kevin Wolf wrote:
> 
> > We can choose Markus's suggestion of using the file name to guess the
> > format. I don't really like it much, but it seems like a fair compromise
> > that doesn't hurt usability as much.
> 
> In other words, if a user gives a file a "known suffix", then it is
> their own fault if they made that file raw and the guest then happened
> to convert the file to the format matching the suffix?  Or would this
> start giving warnings if the known suffix doesn't match the probed contents?

You mean if the suffix doesn't match the explicit format=... option?
Because after the malicious guest has done its work, it would match
again.

> > If we don't want this, we can approach the problem from a different
> > angle: The problem is not probing per se, but that images probed as raw
> > can be written to by guests in a way that the next time they are probed
> > as something else.
> > 
> > What if we let the raw driver know that it was probed and then it
> > enables a check that returns -EIO for any write on the first 2k if that
> > write would make the image look like a different format?
> 
> Not entirely future-proof - as we add support for more formats over
> time, something that passes today could fail in the future.  Worse, a
> guest could exploit an older qemu to write a header that a newer qemu
> would reject.  But it does sound like an interesting approach
> (preventing the guest from doing something risky).

With qemu updates (or different configure options), it could happen that
the behaviour changes, yes. But if a malicious guest has to figure out
how to write a header today that will allow it to read some file on the
host after the user replaces the qemu binary, that makes it probably
hard to exploit anything in practice.

And seriously, if I wanted to use the backing file to read something on
the host, I wouldn't mess with the guest OS trying to rewrite its raw
image into qcow2 while not destroying itself (has anyone tried to write
a proof of concept for this? It doesn't look trivial if you have e.g. a
normal Linux installation that is getting hacked), but just offer the
user some (real) qcow2 for download that already has the desired backing
file path in it...

Kevin

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]