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?
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list