Re: [libvirt] backing file chains, -blockdev, and storage file autodetection
On Wed, Jan 08, 2020 at 15:34:02 +0000, Martin Wilck wrote:
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:
[...]
> 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.
Well yeah. The thing is that if you want to allow format probing you
must declare somehow that you trust the image itself. The simplest way
is just to declare the format in the first place to avoid any
out-of-band metadata.
In fact, with the new libvirt you can override the format of the backing
image by directly specifying it in the XML which is basically
out-of-band metadata storage.
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.
Well, in the general scenario, you can e.g. assume that the VM has
another disk where the malicious guest could do shenanigans without
breaking itself.
> 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 failure with selinux is a bit different. The backing file is not
labelled and thus can't be opened resulting in an hard failure during
qemu startup.
I agree completely that the fact that we didn't reject if the backing
file didn't have a format right away in 5.10 was a rather big overlook
from my side. Especially since there were already bugs and described
failure scenarios.