Open Stack

Hello,

So if I understand You correct, it is not so dangeorus if I'm using
ibvirt with apparmor and this libvirt is adding apparmor rules for
every qemu process, yes?

-- 
Best regards / Pozdrawiam
Sławek Kapłoński
slawek at kaplonski.pl

On Wed, May 13, 2015 at 04:01:05PM +0100, Daniel P. Berrange wrote:
> On Wed, May 13, 2015 at 02:31:26PM +0000, Tim Bell wrote:
> > 
> > Looking through the details of the Venom vulnerability,
> > https://securityblog.redhat.com/2015/05/13/venom-dont-get-bitten/, it
> > would appear that the QEMU processes need to be restarted.
> > 
> > Our understanding is thus that a soft reboot of the VM is not sufficient
> > but a hard one would be OK.
> 
> Yes, the key requirement is that you get a new QEMU process running. So
> this means a save-to-disk followed by restore, or a shutdown + boot,
> or a live migration to another (patched) host.
> 
> In current Nova code a hard reboot operation will terminate the QEMU
> process and then start it again, which is the same as shutdown + boot
> really. A soft reboot will also terminate the QEMU process and start
> it again, when when terminating it, it will try to do so gracefully.
> ie init gets a chance todo a orderly shutdown of services. A soft
> reboot though is not guaranteed to ever finish / happen, since it
> relies on co-operating guest OS to respond to the ACPI signal. So
> soft reboot is probably not a reliable way of guaranteeing you get
> a new QEMU process.
> 
> My recommendation would be a live migration, or save to disk and restore
> though, since those both minimise interruption to your guest OS workloads
> where as a hard reboot or shutdown obviously kills them.
> 
> 
> Also note that this kind of bug in QEMU device emulation is the poster
> child example for the benefit of having sVirt (either SELinux or AppArmor
> backends) enabled on your compute hosts. With sVirt, QEMU is restricted
> to only access resources that have been explicitly assigned to it. This
> makes it very difficult (likely/hopefully impossible[1]) for a compromised
> QEMU to be used to break out to compromise the host as a whole, likewise
> protect against compromising other QEMU processes on the same host. The
> common Linux distros like RHEL, Fedora, Debian, Ubuntu, etc all have
> sVirt feature available and enabled by default and OpenStack doesn't
> do anything to prevent it from working. Hopefully no one is actively
> disabling it themselves leaving themselves open to attack...
> 
> Finally QEMU processes don't run as root by default, they use a
> 'qemu' user account with minimal privileges, which adds another layer
> of protection against total host compromise
> 
> So while this bug is no doubt serious and worth patching asap, IMHO,
> it is not the "immediate end of the world" scale disaster that some
> are promoting it to be.
> 
> 
> NB, this mail is my personal analysis of the problem - please refer
> to the above linked redhat.com blog post and/or CVE errata notes,
> or contact Red Hat support team, for the official Red Hat view on
> this.
> 
> Regards,
> Daniel
> 
> [1] I'll never claim anything is 100% foolproof, but it is intended to
>     to be impossible to escape sVirt, so any such viable escape routes
>     would themselves be considered security bugs.
> -- 
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-manager.org :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators