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

[Stefan Hajnoczi <stefanha@gmail.com>]

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 <stefanha@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
>