[libvirt] Investigation and possible fix of 1361592 - apparmor profiles do not include backing files

[Peter Krempa]

On Thu, Aug 16, 2018 at 23:03:40 +0300, Povilas Kanapickas wrote:
> On 16/08/2018 10:38, Peter Krempa wrote:
> > To fix this you should record the backing format [1] into your overlay
> > image. If we'd relax the code we'd face the regression in the security
> > fix we've done.
> > 
> > [1] qemu-img creage -f qcow2 -F qcow2 -b backing-qcow2 overlay.qcow2
> > 
> > -F option specifies the format of the backing file
> > 
> 
> Thanks a lot for your explanation, now I see that my proposal does not
> make any sense. Your suggestion works fine and virt-aa-helper produces
> correct output.
> 
> Do you think this situation should ideally be diagnosed by higher-level
> tools such as virt-manager which right now emit a generic permission
> denied error?

The current way things are implemented is that we don't even try to
probe the type of the backing file if the format is not specified so the
libvirt code is not sure whether the backing image is raw or not.

We certainly can propagate the fact inside libvirt but we can't fail
startup of the VM in such case since the image might have been raw in
fact which would be safe to do and the VM will start. Reporting warnings
is generally possible but they end up in the logs only which is not
entirely obvious.

In case of virt-manager it's not as easy. virt-manager needs to be able
to operate on remote connections (thus not be able to inspect the files
present locally if they are not present in a libvirt storage pool) this
means that since it will not get an error from libvirt and is not able
to inspect the files it's hard to implement such a warning.

> Maybe virt-aa-helper could also emit a comment into the apparmor profile
> saying something like "image.img has a backing image xyz.img but it was
> not probed because its format is not recorded into the overlay image"?

As this is using libvirt's image detection code it may be possible to
add a field in the virStorageSource structure where we note that the
format was assumed as raw due to failed format detection. The
virt-aa-helper then could print that message in such case.

From libvirt's point of view the warning could be recorded in the VM log
file. The problem still is that it may work in some cases. Or even the
VM may start, but the contents of the disk will be corrupted.

Currently we just don't allow qemu to use any of the backing files if
the format detection has failed, but that does not mean that qemu will
not attempt to open it as qcow2.

On the other hand with the upcomming -blockdev work, we will be able to
tell qemu to open the image as raw instead so the guest will most
probably get garbled content.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180817/6eed0f6c/attachment-0001.sig>