[libvirt] On pidfile security and using -daemonize to start qemu/kvm

[Charles Duffy]

I had a brief conversation with Daniel Berrange on IRC this morning 
regarding race conditions in libvirt's invocation of qemu domains. The 
preferred approach from qemu's maintainership is using -daemonize at 
invocation, and then waiting for the process to exit before attempting 
to connect to the monitor; after this occurs, qemu guarantees monitor 
availability, so no retry/timeout behavior is necessary.

Dan pointed out an issue with this approach:

To determine the PID of the qemu instance started, the -pidfile argument 
to qemu needs to be used with -daemonize. However, -pidfile writes the 
requested pidfile with qemu's permissions; if the guest were subverted, 
it could rewrite its pidfile and lead libvirt to kill other, arbitrary 
processes.

Neither changing permissions with -runas rather than prior to invocation 
nor chown'ing the pidfile from libvirt after creation helps, as qemu 
keeps a file handle on it open throughout operation (to maintain a POSIX 
lock on the file).


However, a workaround exists, and it meshes well with a security fix 
which needs to be implemented anyhow:

At present, on initial startup or libvirtd restart, we read the PIDs 
associated with vCPUs from the monitor in virDetectVcpuPIDs(); doing 
this on libvirtd restart poses a security risk for the reason given 
above, so we need to have libvirtd record the PIDs on initial startup 
(before any untrusted code within the guest is ever run) regardless.

If we also read the libvirtd pidfile at this same early time (before the 
guest has been started and thus had an opportunity to run untrusted 
code) and include its contents when writing out the vCPU PIDs, this 
would eliminate the issue with pidfile ownership blocking use of -daemonize.

Thoughts?