Sorry, I forgot to include Daniel Berrange who might have thoughts about a nice way of running the privileged virtfs helper and how to integrate with libvirt.
On Tue, Sep 6, 2011 at 3:48 PM, Stefan Hajnoczi <stefa...@gmail.com> wrote: > On Mon, Sep 05, 2011 at 09:48:21PM +0530, M. Mohan Kumar wrote: >> Qemu need to be invoked by root user for using virtfs with passthrough >> security model (i.e to use chroot() syscall). >> >> Question is: Is running qemu by root user expected and allowed? Some of the >> virtfs features can be utilized only if qemu is started by root user (for >> example passthrough security model and handle based file driver need root >> privilege). >> >> This issue can be resolved by root user starting qemu and spawning a process >> with root privilege to do all privileged operations there and main qemu >> process dropping its privileges to avoid any security issue in running qemu >> in >> root mode. Privileged operations can be done similar to the chroot patchset. >> >> But how to determine to which user-id(ie non root user id) qemu needs to drop >> the privileges? Do we have a common user-id across all distributions/systems >> to which qemu process can be dropped down? Also it becomes too complex i.e >> when >> a new feature needing root privilege is added, a process with root privilege >> needs to be created to handle this. >> >> So is it allowed to run qemu by root user? If no, is it okay to add the >> complexity of adding a root privilege process for each feature that needs >> root >> privilege? > > I believe libvirt performs the privilege dropping itself and then > invokes QEMU. So in the context of KVM + libvirt we do not have > privileges in QEMU. Of course the administrator can edit > /etc/libvirt/qemu.conf and configure the user to run QEMU as (i.e. > root). But the intention here is to run QEMU unprivileged. > > QEMU has its own -runas switch which may be used when QEMU is run > directly by a user or by custom scripts. This switch looks up the user > and switches to their uid/gid/groups. > > We need to think carefully before adding privileged features to QEMU > since they usually require extra configuration to safely limit the group > of users who may use the feature. These features will be unavailable to > unprivileged users on a system. > > The main part of QEMU (vcpu execution and device emulation) should never > run privileged. This way attacks on QEMU's code are limited to giving > unprivileged access on the host. > > A virtfs feature that needs root therefore needs to be in a separate > process. Either QEMU needs to fork or virtfs could use a separate > daemon binary. > > You have already implemented the fork approach in the chroot patches. > Handle-based open could work in the same way. > > To summarize this architecture: all path-related operations are > performed by a separate privileged process. File descriptors are passed > to QEMU over a UNIX domain socket. This way QEMU can do the actual > read(2)/write(2) calls directly to/from guest memory. > > I think it would be nice to build a completely separate binary that QEMU > connects to. The separate binary would have a much smaller footprint > (doesn't include QEMU code). More importantly the > privileged/unprivileged boundary would be simple and could be > automatically set up by libvirt: > > $ sudo namespace_helper --sock /var/run/virtfs/1234.sock --export my_dir/ > $ qemu -fsdev local,id=my_fs,namespace_helper=/var/run/virtfs/1234.sock \ > -device virtio-9p-pci,fsdev=my_fs > > Stefan >
