From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:58348) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0wyC-0000ad-NG for qemu-devel@nongnu.org; Tue, 06 Sep 2011 10:49:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R0wy6-0002vz-6O for qemu-devel@nongnu.org; Tue, 06 Sep 2011 10:49:48 -0400 Received: from mail-gw0-f45.google.com ([74.125.83.45]:40984) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R0wy6-0002vs-2X for qemu-devel@nongnu.org; Tue, 06 Sep 2011 10:49:42 -0400 Received: by gwb19 with SMTP id 19so3959861gwb.4 for ; Tue, 06 Sep 2011 07:49:41 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20110906144822.GA27940@stefanha-thinkpad.localdomain> References: <1315239516-4451-1-git-send-email-mohan@in.ibm.com> <20110906144822.GA27940@stefanha-thinkpad.localdomain> Date: Tue, 6 Sep 2011 15:49:41 +0100 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH V12 00/15] virtio-9p: chroot environment for passthrough security model List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "M. Mohan Kumar" Cc: qemu-devel@nongnu.org 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 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 (fo= r >> example passthrough security model and handle based file driver need roo= t >> privilege). >> >> This issue can be resolved by root user starting qemu and spawning a pro= cess >> with root privilege to do all privileged operations there and main qemu >> process dropping its privileges to avoid any security issue in running q= emu in >> root mode. Privileged operations can be done similar to the chroot patch= set. >> >> 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/sys= tems >> 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 privi= lege >> 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 need= s root >> privilege? > > I believe libvirt performs the privilege dropping itself and then > invokes QEMU. =A0So in the context of KVM + libvirt we do not have > privileges in QEMU. =A0Of course the administrator can edit > /etc/libvirt/qemu.conf and configure the user to run QEMU as (i.e. > root). =A0But 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. =A0This 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. =A0These features will be unavailable t= o > unprivileged users on a system. > > The main part of QEMU (vcpu execution and device emulation) should never > run privileged. =A0This 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. =A0Either 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. =A0File descriptors are passe= d > to QEMU over a UNIX domain socket. =A0This 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. =A0The separate binary would have a much smaller footprint > (doesn't include QEMU code). =A0More 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=3Dmy_fs,namespace_helper=3D/var/run/virtfs/1234.so= ck \ > =A0 =A0 =A0 -device virtio-9p-pci,fsdev=3Dmy_fs > > Stefan >