From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gh7bT-0006nQ-DM for qemu-devel@nongnu.org; Mon, 06 Nov 2006 11:45:43 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gh7bO-0006eU-F5 for qemu-devel@nongnu.org; Mon, 06 Nov 2006 11:45:42 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gh7bO-0006e1-0g for qemu-devel@nongnu.org; Mon, 06 Nov 2006 11:45:38 -0500 Received: from [199.232.41.67] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1Gh7bN-0000WW-Jz for qemu-devel@nongnu.org; Mon, 06 Nov 2006 11:45:37 -0500 Received: from [212.227.126.186] (helo=moutng.kundenserver.de) by mx20.gnu.org with esmtp (Exim 4.52) id 1Gh7Cf-0001KR-99 for qemu-devel@nongnu.org; Mon, 06 Nov 2006 11:20:05 -0500 Date: Mon, 6 Nov 2006 17:20:00 +0100 From: Chris Friedhoff Subject: Re: [Qemu-devel] qemu and kernel 2.6.18 Message-Id: <20061106172000.f09cfedb.chris@friedhoff.org> In-Reply-To: References: <9b0d5f320610131000x744ce6cagd549f4ec0e1ac9f7@mail.gmail.com> <20061014094706.a59e3e33.chris@friedhoff.org> <92c265230610150031h570a1cfenedc723b9a9949a25@mail.gmail.com> <20061016103648.8f2dfe23.chris@friedhoff.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Capabilities split the root privilege up in certain rights -> capabilities. Beside the fact that the kernel asks for certain capabilities it doesnt provide the use of capabilities. I'm using Serge E. Hallyn "introduce fs caps" patch (http://lkml.org/lkml/2006/9/6/229) and Kaigai Kohei's userspace tools to grant the qemu binary the needed cap_net_admin capability. Qemu is now running without patching kernels tun.c or setting qemu root-suid-bit. See here for a HowTo my experience: http://www.friedhoff.org/fscaps.html Chris On Tue, 17 Oct 2006 14:29:28 +0200 "G Portokalidis" wrote: > I thought the best way to overcome the restriction imposed in tun/tap > interfaces is to set qemu as suid, and revoke privileges as soon as > the network interfaces are configured, and before any virtual block > devices are opened. > > I wrote this little patch, which hopefully does just that. > > Cheers, > George > > > On 16/10/06, chris friedhoff wrote: > > Hi, > > > > checking the Changelog for 2.6.18 (and diffing) one can see, that the CAP_NET_ADMIN requirement was added for the tun/tap inerface in tun.c. The question is, is it acceptable for a user to add a tun/tap interface in a running system. It was before 2.6.18. A different approach is, to grant the user or the process the CAP_NET_ADMIN capabillity. > > If the user of the system running qemu is in control of the system, he might start qemu as root. The tun/tap interface is created (due to root-rights), but i wouldn't like to see windows running in a root started qemu. > > Running qemu with kqemu, you need to be able to modprobe kqemu in a root context. If a user has the right to modprobe a module, he can do anything. What might be critical is that a user-context started app might create also a tun/tap interface (for evil reason) without the knowledge of the user. But than one has to ask, what kind of software is he running. > > But nevertheless, if you patch the kernel, you have to know what you do ... > > > > The changelog: http://lwn.net/Articles/190305/ (search for tuntap) > > > > Chris > > > > ######################################## > > > > On Sun, 15 Oct 2006 15:31:11 +0800 > > Tace wrote: > > > > > Hi, > > > That might be some security issues with removal of that capability > > > check. I think it is not a good idea to remove it. > > > > > > 2006/10/14, chris friedhoff : > > > > Hello, > > > > > > > > bringing up the tun/tap interface depends now on the capability CAP_NET_ADMIN, which usually only root has. > > > > This patch just removes this dependency, so normal user rights suffices again to bring up the tun/tap interface. > > > > > > > > diff -ruN linux-2.6.18-orig/drivers/net/tun.c linux-2.6.18/drivers/net/tun.c > > > > --- linux-2.6.18-orig/drivers/net/tun.c 2006-09-20 05:42:06.000000000 +0200 > > > > +++ linux-2.6.18/drivers/net/tun.c 2006-10-02 09:21:52.000000000 +0200 > > > > @@ -489,9 +489,6 @@ > > > > > > > > err = -EINVAL; > > > > > > > > - if (!capable(CAP_NET_ADMIN)) > > > > - return -EPERM; > > > > - > > > > /* Set dev type */ > > > > if (ifr->ifr_flags & IFF_TUN) { > > > > /* TUN device */ > > > > > > > > -------------------- > > Chris Friedhoff > > chris@friedhoff.org > > > > > > _______________________________________________ > > Qemu-devel mailing list > > Qemu-devel@nongnu.org > > http://lists.nongnu.org/mailman/listinfo/qemu-devel > > > -------------------- Chris Friedhoff chris@friedhoff.org