[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] German BSI analysed security of KVM / QEMU
From: |
Cornelia Huck |
Subject: |
Re: [Qemu-devel] German BSI analysed security of KVM / QEMU |
Date: |
Fri, 13 Oct 2017 11:53:10 +0200 |
On Fri, 13 Oct 2017 10:44:00 +0100
"Daniel P. Berrange" <address@hidden> 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 <address@hidden> 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.