[libvirt] On pidfile security and using -daemonize to start qemu/kvm
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?
On Wed, Sep 02, 2009 at 02:08:37PM -0500, Charles Duffy wrote:
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.
That sounds like it is worth a try at least. Just remmber the 3 scenarios to test - libvirtd as root, qemu configured to run as root - libvirtd as root, qemu configured to run as qemu - libvirtd as a normal user, qemu matching If you can get something that launches QEMU in all these scenariso then you're onto a winner. Oh, and make sure you have capng installed/enabled at build time because that may cause a little fun too REgards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
participants (2)
-
Charles Duffy -
Daniel P. Berrange