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 [email protected] 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators _______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
