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?
The option of using LUKS on the host is mentioned, but also that libvirt
doesn't support this, so it comes with manual work.
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")
> 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.
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. :-(
Kevin
