Re: [Qemu-devel] [PATCH V12 00/15] virtio-9p: chroot environment for passthrough security model

[Stefan Hajnoczi]

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