Re: [Qemu-devel] qemu and kernel 2.6.18

[Chris Friedhoff <chris@friedhoff.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" <georgios.portokalidis@gmail.com> 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 <chris@friedhoff.org> 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 <tacetan@gmail.com> 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 <chris@friedhoff.org>:
> > > > 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