9:34 a.m.
Hi Peter,
On Wed, 2020-01-08 at 15:46 +0100, Peter Krempa wrote:
On Wed, Jan 08, 2020 at 13:34:14 +0000, Martin Wilck wrote:
> The recent change in libvirt to pass storage arguments to qemu via
> "-blockdev", explicity passing backing file chain information
> rather
> than relying on qemu to figure it out, has bitten me quite
> painfully.
I'm sorry for causing this. I'm also sorry for going to sound too
dismissive later on.
Thanks for your reply anyway.
> Meanwhile I've fixed my VM images by adding the backing file
format
> tag, as suggested in the documentation. However I still think that
> this
> was quite a disruptive change and highly unexpected for users. IMO
> the
> default behavior shouldn't have been switched like this without
> appropriate warnings.
This is a good sounding idea but mostly pointless when attempting to
pull off.
If we'd add notes in the documentation, most people wouldn't read
them
until stuff breaks. Similarly for putting warnings into the code.
They
end up in the log file and not many people even bother to read them.
Well, as soon as things break, some people start reading the log files.
The release notes problem is familiar of course. I guess we all have
it, both sides (neither do people read my release notes, nor do I read
theirs).
Part of the reason I posted this was hope that it will help others
figure out the issue more quickly in the future.
> The rationale given for not autodetecting the file format is
"a
> malicious guest could rewrite the header of the disk leading to
> access
> of host files". I suppose a guest would need to manipulate a raw
> image
> to look like qcow2, qed or similar for this to happen (and set the
> backing file to "/etc/shadow", maybe?). Still the malicious guest
> would
> need to find a way to manipulate the data *on the backing store*,
> because the format of the topmost image is explicit anyway.
> Modifying the backing store could be difficult for the guest,
> because
> it's normally read-only and changes go only to the top layer. Or am
> I
You are right in cases when the backing image is always a backing
image.
That can't be guaranteed though because the VM may use the image as
the
only image in raw mode. Then when an overlay is created the image may
already be compromised. Obviously this requires the permission to do
the
overlay, which can arguably not be granted. In general though this
scenario is possible.
OK, I didn't think of that. My personal use case is to create af fresh
install and use that as read-only base image for various VMs, never
using it directly any more.
I think this attack would be possible if autodetection was very basic
(e.g. just looked at the file magic). Trying to fool a more
sophisticated format autodetection without shooting itself into the
foot (by destroying its own file system) would be quite hard for a
guest, I believe. But I lack knowledge about the qcow2 format to really
judge that.
In libvirt we already always record the image format when creating
the
overlay for many years now.
Unfortunately almost all tutorials about backing chains on the web just
teach qemu-img usage. In my case I guess it's just an old habit.
While I can't deny that an attack like this might be feasible, I
am
> still wondering why this hasn't been an issue in past years (with
> qemu
> auto-detecting the backing file format).
Well, for distros using selinux this attack is mitigated by selinux
usage. That was also the reason why "assuming raw" was good enough.
Not sure I'm getting that. Assuming "raw" wrongly could lead to massive
data corruption in the guest, unless I'm mistaken. I wonder how SELinux
would prevent that...
The option to allow autodetection was removed some time ago with the
rationale that it's not worth even allowing reverting to an insecure
configuration.
While this will cause a disruption during upgrade, users will need to
modify the custom scripts. Unfortunately that would have to hapen in
one
way or another anyways.
Hm, this doesn't make me happy but I guess it's how it is.
Also I'm not really sold on the idea of matching qcow2 in the
image
name. It's just another bit of metadata, you can record it properly
in
the overlay. (*)
* I will need to think about this for a bit first.
Thanks.
Martin
--
Dr. Martin Wilck <mwilck(a)suse.com>, Tel. +49 (0)911 74053 2107
SUSE Software Solutions Germany GmbH
HRB 36809, AG Nürnberg GF: Felix
Imendörffer