An FYI on this Forum thread…
Perhaps I personally should have done less assuming and applied myself to KVM/QEMU security assuming nothing a long time ago.
So, have done some quick skimming of relevant articles addressing what I feel is a really serious security hole, on a personal machine perhaps allowing User direct access to managing virtualization can be YMMV but should be considered an extremely serious issue of the highest importance in a Production deployment.
Since I’ve only been looking into this for a very short time, currently anything I post on this should be considered “In Progress” and advice that must be double-checked. Maybe after some extensive reading and testing I might feel like posting something that might be considered authoritative in the future… But, unless I run into someone who is expert on this topic, it’ll likely be awhile…
What I’m writing here is preliminary and although is primarily about KVM/QEMU, it’s likely applicable to all community virtualization and probably doesn’t apply to commercial products (like VMware).
It should also be noted that SUSE and openSUSE documentation is completely silent on virtualization security, and describe only general machine security. Virtualization security requires additional steps and/or knowledge.
First, the libvirt architecture is the right design, it separates management completely from running Guests, and that extends also to the security model. This means that no matter how you configure access to libvirt User tools, the Guests run in a different security context which is a dedicated non-login User account “qemu.” The consequence is multi-fold and includes the fact that if somehow a Guest process escaped its sandbox, it could be limited in what it might see or access including HostOS files and physical hardware.
I’m a bit dismayed that kvm and qemu commands don’t apply a similar architecture, one way by applying similar permission management on the API level which AFAIK is quite do-able. And so, by default as people have posted in this thread ordinary Users can use scripting commands to access virtualization management because that’s the Linux default.
Therefor,
IMO the first step then should be to find all the alternate ways of managing virtualization other than by libvirt, and their permissions should be set to deny access by the setuid or setgid bits for non-root Users… And there are many kvm and qemu binaries to modify. Maybe an AppArmor or SELinux policy should be built to do this.
Next step is to decide what security policy to apply.
Although AppArmor is default on an openSUSE/SUSE, IMO SELinux should be strongly considered because AppArmor application flexibility likely isn’t needed for a Production HostOS machine which should be a single purpose machine anyway.
If you do decide to switch over to SELinux, do so(there was another thread about how to do this within the past couple months in these Forums which I also posted in), then IMO the following RedHat documentation should apply completely except possibly the sections on sVirt (I’m still researching if that is available on openSUSE/SUSE)
As far as openSUSE/SUSE support for SELinux/sVirt, I only found some incomplete attempts to build some modules about 8 months ago.
sVirt is optional but might not be possible on an openSUSE/SUSE SELinux today, but a nice feature if available. This is one of those things I’m going to research that will take time. sVirt is <very> desirable, for those situations where you want to grant multiple Users rights to manage your virtualization, adding the Users to the libvirtd group enables each User full access to every virtualization management function. sVirt allows you to set fine-grained rights, so for instance some Users can be granted rights to start/stop Guests but not to further modify or create new Guests.
One of the benefits of choosing SELinux is that there are more published articles about using it to lock down a HostOS, but you can stay with AppArmor, too. If you do so, the following article describes how to configure Appmor but it seems that AppArmor support for sVirt is not available today. Even if you use AppArmor, read the above Red Hat reference for general configuration best practices, in particular security issues relating to configuring Guest direct access to raw/physical devices and file systems, and access to hardware peripherals.
http://wiki.apparmor.net/index.php/Libvirt
HTH and Stay Safe,
TSU