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

[Markus Armbruster]

Paolo Bonzini <address@hidden> writes:

> 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.

If we had a "no format probing" option in qemu-nbd (not in my patch, but
that's a flaw in the patch, not the idea), then libvirt developers
would've put it to use right away, and then their insecure usage
would've failed hard, making it immediately obvious.

My point is: we don't have to perfect libvirt before we can provide it a
safe failure mode.  The safe failure mode will actually assist with
perfecting libvirt, by making the failures immediately fatal.

> 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.

I agree secure usage is currently is too hard for casual command line
use.

Unfortunately, it has proven too hard even for sophisticated
programmatic users like libvirt.  I refuse to blame libvirt for that.
Secure usage really shouldn't be that hard.

>  Also, I suspect any advice to QEMU users about adding
> --no-format-probing would be quickly forgotten.

When we discussed security issues with probing last year, my first line
of defense was "the default should be secure".  Overwhelming opposition
from the backward compatibility camp forced me to retreat from that line
to my second line of defense "secure shouldn't be hard".  That line
needs to be held at all costs :)

"Always specify --no-format-probing" (or however else we label the knob)
is workable advice for programmatic users like libvirt.  I agree it's
hardly helpful advice for human users.  For them, the advice needs to be
something like "add the following stanza to ~/.qemu.conf, then forget
about it".

Same thing, different user interface.

~/.qemu.conf isn't currently used, but it could be.

> 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.

Debating which use case is "better" and more interesting doesn't seem to
be wortwhile.  I think both are interesting enough.

> 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.

Putting it in a security option group is certainly fine with me.  I
picked "misc" only because I couldn't find a better fit, and I could see
other readconfig-incapable options where I couldn't find a better fit,
either.

> 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.

For whom you want it to get done isn't as important to me as getting it
done :)

>                                                         But I still
> maintain that for libvirt this is basically security theater, and the
> priorities are others.

To be honest, I find your use of "security theater" offensive.

I'd readily accept the moniker if the feature would provide libvirt
developers an excuse not to fix their bugs, or reduce the incentives to
fix their bugs.

But the feature in fact does the opposite: it makes such bugs blatantly
obvious and release-blocker-painful.