Re: [Qemu-devel] German BSI analysed security of KVM / QEMU

[Daniel P. Berrange]

On Mon, Oct 16, 2017 at 03:22:46PM +0200, Kevin Wolf wrote:
> Am 13.10.2017 um 11:44 hat Daniel P. Berrange geschrieben:
> > On Fri, Oct 13, 2017 at 11:37:08AM +0200, Cornelia Huck wrote:
> > > - Lack of support for encryption/signing of network-based images was
> > >   criticized. They ended up using Ceph and GlusterFS, which they were
> > >   reasonably happy with.
> > 
> > Hopefully the 'luks' driver (which can be layered over any block backend
> > including network ones), and the TLS support for NBD would be considered
> > to address this last point to some degree. At least from the encryption
> > side.
> 
> They refer to a blog post of yours about the weakness of the AES
> encryption in qcow2, but it seems they didn't see that luks exists as a
> replacement. While the qcow2 integration of luks is new in 2.10, we've
> had the separate 'luks' driver for a while. Do we need to inform our
> users better about it?

There is definitely room to improve our docs and general presentation
of QEMU security features.

> The option of using LUKS on the host is mentioned, but also that libvirt
> doesn't support this, so it comes with manual work.

Yep

> They saw the TLS support in NBD, but had the impression it's not mature:
> 
>     nbd sieht zwar einen Schutz durch TLS vor, dieser wird jedoch als
>     experimentell bezeichnet und nicht für den produktiven Betrieb
>     empfohlen.
> 
> ("nbd provides protection by TLS; however, this is described as
> experimental and not recommended for production")

They probably read the old version of the NBD protocol specification
from early 2016 where TLS was still listed as "Experimental", due to
not having any implementation of the TLS spec. This "Experimental"
tag was removed after we released TLS in QEMU


> > Signing of disk images is impractical as it would imply having to download
> > the entire image contents to validate signature, rather defeating the point
> > of having a network based image. But perhaps this is lost in translation
> > and they mean something else by "signing of images" ?
> 
> I suppose they mean something on a per-block basis, like a checksum or
> hash that is included in the encryption and can be used to verify that
> nobody changed the encrypted data from outside.
> 
>     Darüber hinaus besitzt qcow2 keinerlei Integritätsschutz. Selbst wenn
>     die Verschlüsselung als ausreichend sicher angesehen werden würde, so
>     ist es dem Angreifer prinzipiell weiterhin möglich, den Inhalt des
>     Blockgeräts zu modifizieren
> 
> ("In addition, qcow2 has no integrity protection. Even if the
> encryption were considered sufficiently secure, in priciple the attacker
> could still modify the content of the block device.")
> 
> They mention dm-integrity as an option to implement this on the host
> kernel level.

Ah ok. I would think the user could  still run dm-integrity inside their
guest if they wanted to detect tampering explicitly instead of getting
back garbage decrypted data.

> Another thing that made me a bit sad is that they mention qed as a
> better performing alternative for qcow2. Even in 2017, people keep
> spreading this nonsense. :-(

Probably because when you google for QED you inevitably hit this article
near the top:

  https://www.phoronix.com/scan.php?page=news_item&px=OTY0MQ

And there's little clear information on QEMU website to show that QED
is essentially an obsolete experiment.

Perhaps some clear update to this page would help, and also in the
qemu docs

  https://wiki.qemu.org/Features/QED


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|