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" <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>: > > > > 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 > > [EMAIL PROTECTED] > > > > > > _______________________________________________ > > Qemu-devel mailing list > > Qemu-devel@nongnu.org > > http://lists.nongnu.org/mailman/listinfo/qemu-devel > > > -------------------- Chris Friedhoff [EMAIL PROTECTED] _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
