I’ve set a learning project for this weekend - setting up KVM with PCIe Passthrough. It would be awesome if I could set up a VM machine in a way regular users could see / access it , or even better if users that belong to certain group could browse VMs or add their own. How do I set it up?
Take a peek at; https://doc.opensuse.org/documentation/leap/virtualization/book.virt_color_en.pdf
Under heading “10.2.1 “system” Access for Non-Privileged Users”
It shows you how to configure per user or per group permissions to the libvirt interface - allowing non-root users to manipulate, for example, KVM virtual machines.
Providing this advice should always be accompanied with the warning that this should <never> be done on a Production system, and only with great care in all other cases because it opens up a giant security hole in your network, granting <ordinary User accounts> permissions similar to root on a machine in your network.
IMO this warning is so important that it should be in the docs.
As I described in another thread elsewhere in these forums, if compromised a possible scenario could be a virtualized version of the infamous Belgian shipping incident reported by Bloomberg a couple years ago where criminals were able to deploy their own WiFi AP in the network of a major shipping conglomerate. The diff is that in that case, it’s possible for someone to stumble on a physical device. Virtualized, you may have no way of detecting except if you inspected your system processes and threads.
TSU
it’s on the workstation in the (relatively small) workshop so I don’t think it will be a big problem. VM won’t make much sense to me if the users won’t be able to launch those I’ve set and see those. That’s crucial.
It would be awesome (and that’s what I’ve achieved thx to Miuku’s link - added users to kvm, libvirt, qemu groups) if some of the other users will be able to create VMs of their own. But if that’s a huge security problem I won’t pressure for this. But if you could advise how it should be set up you’d rock 
!
Not really any different than giving people sudo permissions which people do all the time.
First,
sudo can be sandboxed to a certain extent so it’s not the same as root.
And, using the same password for root and sudo is unique to openSUSE, if someone wanted to tighten up security, that’s a good place to start particularly when you start granting the power to create machines with full access to the network… That’s a significant security issue compared to granting sudo permissions on a machine with more “ordinary” apps on the machine.
It should be common to create machines that Users can remote into (eg SSH),
But it’s another thing altogether to grant permissions to create, manage, start and restart virtual machines.
Remember that it’s not difficult to create machines that don’t show up in the graphical management console (eg vm manager), and virtual machine files don’t have to be in storage pools along with other machines.
If any one of those ordinary User accounts were compromised and the intruder comes to understand that you granted the ability to create virtual machines, he could easily create machines you won’t likely be able to detect unless you were supernaturally vigilant (or some pretty good IDS).
TSU
Every user can use qemu to run VM. No special “ability” is needed, so there is nothing to “grant” here. Unless you restrict access to qemu binary, but I do not see any restrictions, even in paranoid permissions mode.
If it’s true that running the QEMU binary does not require root permissions, then that is a development I wasn’t aware of (It hasn’t always been that way). Would be interesting to trace the permissions history (likely Apparmor but might also be simply the directory where the binary is located).
TSU
I use it almost every day. I run all my VMs using direct QEMU invocation under my regular account.
Does not?
The way I have always started the Windows VM I have is through Virtual machine manager. This alone can be just started as normal user indeed, but in order to see the virtual machine(s) -and all virtual machine options such as storage, network…- one always needs to “connect” to the qemu server, and that always requires admin privileges!
In other words, I always need to enter root privileges just to start a virtual machine through Virtual machine manager, which is why I’m fearful of, say, using Firefox -and on email- or IRC client while at same time VM running. I have only used Gedit and the terminal -never as root user- while VM running.
Hope someone could illustrate me in this…
A FYI
This topic and various options for authentication including granting ordinary User rights to all management functions, alternate authentication and more is covered in the SUSE 11 SP4 documentation (which should apply 100% to openSUSE as well)
https://www.suse.com/documentation/sles11/singlehtml/book_kvm/book_kvm.html#sec.libvirt.connect.auth
As described in the reference,
Local management <should> be based on Unix Sockets ownership by default, and that should be root/root.
Assuming that you don’t enable an alternative method of authentication, then there are two main ways to overcome root-only management, which are to add the User to the libvirt User Group or modifying PolicyKit.
I’m not in front of a recently built KVM/libvirt HostOS right now,
but the documentation <suggests> that by default ordinary Users <might> be able to read, but not actively modify or create/delete Guests. The reference does not mention start/stop Guests which would be an executable permission which conceivably would not require a write permission.
TSU
On Tue, 24 Oct 2017 15:36:01 +0000, F style wrote:
> In other words, I always need to enter root privileges just to start a
> virtual machine through Virtual machine manager, which is why I’m
> fearful of, say, using Firefox -and on email- or IRC client while at
> same time VM running.
Just because you’ve started a VM in one terminal window as root doesn’t
mean everything running on your system is running as root. If you’re
logged into the desktop as a regular user and you launch Firefox/IRC/
whatever on the desktop (using the icons or a second terminal window),
those are running as the desktop user - not as root.
In a terminal window, you can type:
ps aux
and see in the first column what various processes are running as (and
before you panic at the number of running processes, remember that there
are a lot of standard background processes running - things like kworker
threads are normal and nothing to worry about or panic about. The
important thing is to see the first column showing the user that each
process is running as.)
Jim
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C
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
SELinux is an amazing pile of ******.
There is absolutely no scenario I can see, ANYWHERE, where the benefits of having to spend hours on end configuring selinux policies would outweight the miniscule security you gain from it.
Zero usability, zero benefit.
Nobody wants to create SELinux policy.
So, just apply a policy someone else created.
Unless your machine does something other than what the SELinux policy configures this practice of using someone else’ work should work fine and in this case a Production HostOS should be a dedicated Virtualization HostOS and nothing more.
Agreeing but only so far,
TSU
Small update:
Apparently today sVirt has been fully integrated into libvirt so it might be that no additional modules may be needed.
Will need to research this when I next get an opportunity (or someone beats me to it).
As I posted above,
sVirt might be fully implemented only if you switch from Apparmor to SElinux, and is implemented only through libvirt.
A more full description of sVirt features and design objectives
http://selinuxproject.org/page/Svirt_requirements_v1.0
TSU