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

[Daniel P. Berrange]

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 :|