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@xxxxxxxx>, Tel. +49 (0)911 74053 2107 SUSE Software Solutions Germany GmbH HRB 36809, AG Nürnberg GF: Felix Imendörffer -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
