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

[Cornelia Huck <cohuck@redhat.com>]

On Fri, 13 Oct 2017 10:44:00 +0100
"Daniel P. Berrange" <berrange@redhat.com> wrote:

> On Fri, Oct 13, 2017 at 11:37:08AM +0200, Cornelia Huck wrote:
> > On Fri, 13 Oct 2017 11:10:05 +0200
> > Stefan Weil <sw@weilnetz.de> wrote:
> >   
> > > Hi,
> > > 
> > > the German Bundesamt für Sicherheit in der Informationstechnik
> > > (Federal Office for Information Security) published a study on
> > > the security of KVM and QEMU:
> > > 
> > > https://www.bsi.bund.de/DE/Publikationen/Studien/Sicherheitsanalyse_KVM/sicherheitsanalyse_kvm.html
> > > 
> > > (article only available in German)  
> > 
> > Thanks for posting this!
> > 
> > I only looked at the conclusion for now. Some interesting points:
> > 
> > - They state that QEMU's source code is well structured, readable and
> >   maintainable. I wonder what kind of source code they usually deal
> >   with ;)  
> 
> Most closed source apps are worse than even badly structured open
> source code IME ;-)

Ha, that's true from my experience as well ;)

> 
> > - Most problems noted seemed to be related to signed<->unsigned
> >   conversions, but none were found to be exploitable.
> > - They liked hardening via stack protection, NX, and ASLR, as well as
> >   the mechanisms used by libvirt.
> > - They generally seemed to be happy with QEMU being deployed via
> >   libvirt.
> > - Restrictions imposed via KVM (guest access to some CPU registers)
> >   scored positive points. They did not like that Hyper-V and PMU were
> >   not deconfigurable.
> > - 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.
> 
> 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" ?

Could be my bad translation (they talk about "Verschlüsselung und
Signierung"), but I haven't looked what they actually tried to
accomplish.