From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51879) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R39Is-0004Om-JL for qemu-devel@nongnu.org; Mon, 12 Sep 2011 12:24:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R39In-0000rg-T7 for qemu-devel@nongnu.org; Mon, 12 Sep 2011 12:24:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46548) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R39In-0000r4-Ez for qemu-devel@nongnu.org; Mon, 12 Sep 2011 12:24:09 -0400 Date: Mon, 12 Sep 2011 17:23:55 +0100 From: "Daniel P. Berrange" Message-ID: <20110912162355.GP16275@redhat.com> References: <1315239516-4451-1-git-send-email-mohan@in.ibm.com> <20110906144822.GA27940@stefanha-thinkpad.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20110906144822.GA27940@stefanha-thinkpad.localdomain> Subject: Re: [Qemu-devel] [PATCH V12 00/15] virtio-9p: chroot environment for passthrough security model Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: "M. Mohan Kumar" , qemu-devel@nongnu.org On Tue, Sep 06, 2011 at 03:48:22PM +0100, 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 (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. I agree, regardless of libvirt's needs, p9fs needs to be secure for any non-root user using QEMU. As non-root I should be able todo $ qemu -virtfs $HOME/shared and have strong confidence that symlink attacks can't be used by the guest to access other locations nuder $HOME. > 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. One other idea I just had is 'fakechroot'. This is basically an LD_PRELOAD hack which wraps the C library's native chroot(), open() etc call to do chroot in userspace, thus avoiding a need for root privileges. Either you could just invoke QEMU via fakechroot, enabling your code from these patches to be used as non-root. Or we could take the code from the fakechroot library and use that directly in the p9fs code to apply the path security checks Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|