From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:39725) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3MV8-0007L5-Bk for qemu-devel@nongnu.org; Tue, 13 Sep 2011 02:29:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R3MV7-0006eh-7Z for qemu-devel@nongnu.org; Tue, 13 Sep 2011 02:29:46 -0400 Received: from e28smtp09.in.ibm.com ([122.248.162.9]:35830) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3MV6-0006dw-J1 for qemu-devel@nongnu.org; Tue, 13 Sep 2011 02:29:45 -0400 Received: from /spool/local by in.ibm.com with XMail ESMTP for from ; Tue, 13 Sep 2011 11:59:41 +0530 Received: from d28av01.in.ibm.com (d28av01.in.ibm.com [9.184.220.63]) by d28relay01.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p8D6Tdsf4075708 for ; Tue, 13 Sep 2011 11:59:39 +0530 Received: from d28av01.in.ibm.com (loopback [127.0.0.1]) by d28av01.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p8D6Tdxh026125 for ; Tue, 13 Sep 2011 11:59:39 +0530 From: "M. Mohan Kumar" Date: Tue, 13 Sep 2011 11:59:38 +0530 References: <1315239516-4451-1-git-send-email-mohan@in.ibm.com> <20110906144822.GA27940@stefanha-thinkpad.localdomain> <20110912162355.GP16275@redhat.com> In-Reply-To: <20110912162355.GP16275@redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201109131159.39190.mohan@in.ibm.com> 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: qemu-devel@nongnu.org, "Daniel P. Berrange" Cc: Stefan Hajnoczi > 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 > With fakechroot is that I can still do following: chroot("/etc/cups"); fd = open("../passwd", O_RDONLY); It does not check access beyond the chroot path. Also in virtio-9p case, a modified guest kernel can send a symbolic link and that could resolve outside chroot path. passthrough security model in virtio-9p needs root privilege not only for chroot() syscall but also to do chown and chmod on files created by the guest. So IMHO fakechroot can't be used in this case.