qemu-init

Privileges management

qemu-init is designed with security in mind and does commonly nothing as root. However, in some dedicated cases root privilege escalation is required:

• creating a tap device(s) for a bridged network (default)
• using PCI Passthru (e.g. for a second video card)
• enabling Autostart
• granting access to needed files

We will go a little bit deeper into this later on. Before we continue to go into details please keep in mind always:

The initial and main purpose of qemu-init is to start/stop virtual machines automatically at boot/shutdown of the host!

qemu-init uses a dedicated user (default: qemud) and a dedicated group (default: kvm). Both are configurable at build time. If the user/group names diverge from the default it have to be changed in  conf-build  before an update will be build. From now on these default names will be used further.

The user qemud has a small role in the concept. qemu-init starts all virtual machines with root privileges via  sudo  and then drops the privileges via qemu's  -runas  option¹⁾. If not defined otherwise in the rc-file the user qemud will be used. Additional qemud owns the directories in the install destination and some files. It is required that the user have a home to access virtual machines from remote over ssh (e.g. with the Additional sshd options. It is also recommended to consolidate all files of qemu-init inside the home²⁾.

More important is the group kvm. Most of the privileges will be managed/granted by this group. Ordinary user have to be members of this group. As the group kvm is relative mighty, only trusted users should be added. Members of this group have access to ALL virtual machines handled by qemu-init ³⁾. The group is also used to grants the required dedicated root rights via  sudo  (see here).

Handling root privileges

In general qemu-init provides the minimal required root privileges.

TAP Devices

By default qemu-init uses a bridge network ( -netdev tap ). One - the main - reason to prefer it other qemu's default SLiRP ( -netdev user ) network is, that the latter does (did?⁴⁾) has an issue with ping (ICMP). There are some more. Well, to create a tap device there are root privileges required. Behind the decision to do it the way it is was the fact to prevent the hassle with an over-complex configuration, potential extra tools and stay with KISS.

Note: This (the default bridge) have to be explicitly deactivated in the rc-file. To use SLiRP instead, it shall be configured in the cfg-file.

PCI Passthru

This is a special case. A common use case is to gather direct access of a second physical video card to a virtual machine. In such a case the VM have to be run with root privileges, otherwise the access to the passthru'd pci device will fail. Commonly passthru happens on a single user machine, thus it's assumed the user knows what she/he does.

Enabling Autostart

This is the task of the system administrator. Members in the group kvm have not to be necessarily admins, normally they are ordinary users (or maybe call them operators). Thus these users are never authorized to change the boot process of the system. This point interferes with Files Access also.

Files Access

This is a bit more complex. To operate properly qemu-init needs to use different files. The directories owned by the user qemud have the sgid bit set. Thus all files will be created with the correct group. Thus each member of the group kvm can at least read them. Some files will be created at install time with write access for the kvm. These files will never deleted/re-created by qemu-init but truncated and rewritten (e.g.  vncstatus ). But this is not possible or reasonable always.

Depending at the individual config it could be necessary to write to some files. Lets do an example: The information to start a virtual machine with the host is stored in ETCDIR/autostart. This file is owned by root:kvm with mode 0640 (or different presented:  -rw-r—– ). Only root can write to this file (see Enabling Autostart). But what happens if normal users of the group kvm wants to disable autostart for a virtual machine? Now, internal qemu-init uses  setfacl  to grant write access temporarily (and removes it immediately after the change is done). Refer to the sources to get the details.

Another case are the unix sockets to access the monitor. The sockets will be created if a virtual machine starts with ownership root:kvm and mode 0700 ( srwx—— ), not read/write-able by the kvm group. Similar to the above qemu-init uses  setfacl  to enable read/write access for the group kvm.

Last but not least there is a “feature” with qemu itself. The  -pidfile  parameter of qemu creates the pidfile with mode 0700. It doesn't respect a given  -runas  parameter - thus in our case the pidfile is accessible by root only!⁵⁾ qemu-init changes the mode of the pidfile (using  setfacl ) to be readable by group.