Re: [Qemu-block] [Qemu-devel] [PATCH RFC for-2.3 1/1] block: New command line option --no-format-probing

[Paolo Bonzini]

On 24/03/2015 17:49, Markus Armbruster wrote:
>> But what about migration from newer to older QEMU?  Libvirt even
>> supports QEMU versions where the only way to specify disks is "-hda
>> XYZ", so it is _impossible_ to honor the format=raw specifier.
> 
> If you migrate to a QEMU that doesn't understand the new option, libvirt
> simply won't set it.  You lose the protection against libvirt bugs it
> provides.  Guest won't notice.
> 
> If you somehow manage to find a QEMU old enough to make libvirt use
> format-incapable interfaces, you'll be using insecure format probing on
> the destination.  My patch makes no difference.  Good luck migrating to
> such an old QEMU.

(Didn't mean live migration---sorry, could have simply said "switch").

Based on my reading of the code, libvirt will actually ignore the
allow_disk_format_probing setting, and not do anything about the format
when driving such an old QEMU.  By contrast, if you specify a format and
libvirt invokes an old qemu-nbd without --format, libvirt fails hard.
That's already CVE worthy, isn't it?

So I think an option like this is premature.  libvirt should _first of
all_ ensure that it completely abides by the allow_disk_format_probing
setting, including refusing to drive old QEMUs when format probing is
disabled.  Once libvirt is consistent within itself, we can talk about
what help QEMU can provide.

Perfect is not the enemy of good here.  Good is the enemy of secure.

> As to "near misses don't count": for me, what counts is actual users
> telling me about their difficulties using QEMU securely.  Secure usage
> shouldn't be hard.

The right answer for them is probably "use libvirt" or "use Boxes"
depending on the actual usecase.  Invoking QEMU manually is almost never
the right answer for random untrusted images download from the Internet.
 Also, I suspect any advice to QEMU users about adding
--no-format-probing would be quickly forgotten.

That said, if _humans_ have interest in secure use of QEMU, that's a
much better and more interesting use case than libvirt's, because
libvirt is itself providing a secure management layer.

We have other security options, for example seccomp and FIPS mode.
Format probing definitely falls in this category.  Let's add first of
all a -security grouping, where "-security [all=]on" enables all of them
but it's also possible to control the suboptions individually.  Then we
can add format probing to this category.  The same options can be added
to the utilities.

Let's iron out the kinks and do it for 2.4.  It's a very useful feature
indeed.

But it's something we do for _users_, not for libvirt.  If libvirt wants
to use those features as a parachute, better for them.  But I still
maintain that for libvirt this is basically security theater, and the
priorities are others.

Paolo