HowTo: Use the unprivileged "user session" in virt-manager for rootless virtualization with Qemu and KVM

Ask Fedora
, , , , , , , , ,
1

Background

virt-manager is a graphical interface for the libvirt library, using qemu for machine emulation and kvm for hardware virtualization.

kvm stands for “kernel-based virtual machine” and is a low level hypervisor.

Unlike the (especially on Windows) commonly used hypervisor in Oracle VirtualBox, KVM does not require external kernel modules, and runs on a vanilla Linux kernel.

This makes it less troublesome to use than VirtualBox for example, and also more performant.

Links:

Libvirt privileges

By default, virt-manager offers a QEMU system session.

To use this, a user needs to be in the wheel group (the “administrators”) and enter the user password every time.

Alternatively, they can be in the libvirt group, where no password is needed.

The issue, is the broad access this requires. Access to the system libvirt socket is equal to root access on the host OS.

So if there is no other need, it is safer to use a QEMU user session.

QEMU user session

GNOME Boxes stands out, as it allows running virtual machines, while being a flatpak application.

It achieves this by running an unprivileged user session only.

Using the unprivileged user session prevents the use of a few advanced features, that may not be important for many users though.

GNOME Boxes also has fewer features, and the Flatpak has further restrictions.

So here is how to use the same mode in virt-manager:

Setup

Virt-manager also supports running an unprivileged QEMU user session:

  1. Open virt-manager, exit the password prompt with Esc
  2. Right-click on the “QEMU system session” and delete it
  3. Under “File” add a new session, choose “QEMU user session”
  4. Now proceed to create your virtual machines as usual

Done! It is that easy.

You can also have a system and a user session at once, and just stop the system session from connecting.

2

Its libvirt group membership that makes virt manager work without needing passwords.

1 Like
3

Yes that is what I meant to write, do you have a better wording?

  1. Users need to be in wheel AND enter a password
  2. Alternatively, they can be in the libvirt group

I edited it :slight_smile:

4

I do not see the need to mention root or wheel, just confuses things.

Suggested replacement:

Add the user to the libvirt group to avoid the need to enter a password to use virt-manager.

5

I wouldnt advise that as libvirt equals to root access. It could be deduplicated, but this is an issue. I dont have a source for that I just trust @siosm on that

6

Seems like a good start to an amendment of the virtualization section in QuickDocs (which content is up to 4-5 years old now).

1 Like
7

The point of the libvirt groups is to completely avoid the need for a user to ever use root for their VMs. How is that making libvirt == root?

I run a user with libvirt and do not expolit root for my VMs.

1 Like
8

Yes totally, this medium is just nice to write stuff. I will see that I add a lot to the quickdocs.

9

I am not talking about needing to be a root user or in the wheel group.

@siosm told me that having access to the system libvirt socket is easily usable to gain root on the host. I have not looked this up but trust him.

So this is also about privileges. Less privileges, less chance to break your system or get hacked.

If you have an idea for a better formulation, please add :slight_smile:

10

So there needs to be a warning that giving libvirt may allow a user to gain root access?
But we need a citation to the description of the problem.

11

https://bugzilla.redhat.com/show_bug.cgi?id=1284447#c1

From

1 Like
12

Thanks Joe. That was what I was hoping to find.

@boredsquirrel suggest you add a link to the bug with a warning about the risk of using libvirt.

13

*system libvirt

That is the whole point of this guide XD

@grumpey thanks for searching that comment!

I dont think this is a good link to add, I will search for a better one.

I think this here is a really good way to handle howtos before uploads

14

Cheers on the guide, but can we clarify why this would be desirable?

I am not sure that much benefit is to be had from this in terms of security, though certainly some convenience comes from this (namely due to DAC permissions).

From the security angle, a virtual machine launched by libvirt qemu:///system runs as user “qemu” whereas one from qemu:///session runs as your Linux user. Beyond this I notice that for qemu:///session, virtqemud, virtstoraged and virtlogd all run without any type enforcement from SELinux (or any SELinux user/role enforcement); the virtqemud/virtstoraged/virtlogd processes run as root for qemu:///system of course, but they are constrained by type enforcement and are constrained by the SELinux ‘system_u’ (which isn’t meant to be explicitly mapped to a Linux user like sysadm_u or user_u).

All the stuff I can find out there is pretty generic high-level stuff- I wish I could pick Dan Walsh’s brain about this stuff :stuck_out_tongue: I am going to be doing some more research on this and also on confined user accounts in the near future.

2 Likes
15

You are certainly above my knowledge here :slight_smile:

I just follow stone-age logic: no root password, more secure

@dwalsh