[Qemu-devel] qemu and kernel 2.6.18

[Qemu-devel] qemu and kernel 2.6.18

[G Portokalidis]

Hello all,
I have recently installed the latest linux kernel, and i have been
having problems with the tap interface since.

I have been getting the following cryptic message:
warning: could not configure /dev/net/tun: no virtual network emulation
Could not initialize device 'tap'

The tun driver is loaded, and /dev/net/tun is 'rw'.
Any ideas what this is about? Could i have misconfigured something in
the kernel?

Cheers,
George

Re: [Qemu-devel] qemu and kernel 2.6.18

[WaxDragon]

This came up in IRC a few days ago, it seems you need to use the UML
util 'tunctl' to assign permissions to the tap device.  I found this
change annoying.

On 10/13/06, G Portokalidis <georgios.portokalidis@gmail.com> wrote:
> Hello all,
> I have recently installed the latest linux kernel, and i have been
> having problems with the tap interface since.
>
> I have been getting the following cryptic message:
> warning: could not configure /dev/net/tun: no virtual network emulation
> Could not initialize device 'tap'
>
> The tun driver is loaded, and /dev/net/tun is 'rw'.
> Any ideas what this is about? Could i have misconfigured something in
> the kernel?
>
> Cheers,
> George
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>


-- 
22:38 <@WaxDragon> false ^ true
22:39 < false> :(
22:39 < false> dont you think you can XOR me and get away with it! I
always return!

Re: [Qemu-devel] qemu and kernel 2.6.18

[chris friedhoff]

[-- Attachment #1: Type: text/plain, Size: 2145 bytes --]

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

######################################

On Fri, 13 Oct 2006 13:00:10 -0400
WaxDragon <waxdragon@gmail.com> wrote:

> This came up in IRC a few days ago, it seems you need to use the UML
> util 'tunctl' to assign permissions to the tap device.  I found this
> change annoying.
> 
> On 10/13/06, G Portokalidis <georgios.portokalidis@gmail.com> wrote:
> > Hello all,
> > I have recently installed the latest linux kernel, and i have been
> > having problems with the tap interface since.
> >
> > I have been getting the following cryptic message:
> > warning: could not configure /dev/net/tun: no virtual network emulation
> > Could not initialize device 'tap'
> >
> > The tun driver is loaded, and /dev/net/tun is 'rw'.
> > Any ideas what this is about? Could i have misconfigured something in
> > the kernel?
> >
> > Cheers,
> > George
> >
> >
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/qemu-devel
> >
> 
> 
> -- 
> 22:38 <@WaxDragon> false ^ true
> 22:39 < false> :(
> 22:39 < false> dont you think you can XOR me and get away with it! I
> always return!
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel


--------------------
Chris Friedhoff
chris@friedhoff.org

[-- Attachment #2: 2.6.18-tun-without-cap_net_admin-capability.patch.bz2 --]
[-- Type: application/octet-stream, Size: 306 bytes --]

Re: [Qemu-devel] qemu and kernel 2.6.18

[Tace]

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
>
> ######################################
>
> On Fri, 13 Oct 2006 13:00:10 -0400
> WaxDragon <waxdragon@gmail.com> wrote:
>
> > This came up in IRC a few days ago, it seems you need to use the UML
> > util 'tunctl' to assign permissions to the tap device.  I found this
> > change annoying.
> >
> > On 10/13/06, G Portokalidis <georgios.portokalidis@gmail.com> wrote:
> > > Hello all,
> > > I have recently installed the latest linux kernel, and i have been
> > > having problems with the tap interface since.
> > >
> > > I have been getting the following cryptic message:
> > > warning: could not configure /dev/net/tun: no virtual network emulation
> > > Could not initialize device 'tap'
> > >
> > > The tun driver is loaded, and /dev/net/tun is 'rw'.
> > > Any ideas what this is about? Could i have misconfigured something in
> > > the kernel?
> > >
> > > Cheers,
> > > George
> > >
> > >
> > > _______________________________________________
> > > Qemu-devel mailing list
> > > Qemu-devel@nongnu.org
> > > http://lists.nongnu.org/mailman/listinfo/qemu-devel
> > >
> >
> >
> > --
> > 22:38 <@WaxDragon> false ^ true
> > 22:39 < false> :(
> > 22:39 < false> dont you think you can XOR me and get away with it! I
> > always return!
> >
> >
> > _______________________________________________
> > Qemu-devel mailing list
> > Qemu-devel@nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>
> --------------------
> Chris Friedhoff
> chris@friedhoff.org
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>
>
>

Re: [Qemu-devel] qemu and kernel 2.6.18

[chris friedhoff]

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

Re: [Qemu-devel] qemu and kernel 2.6.18

[G Portokalidis]

[-- Attachment #1: Type: text/plain, Size: 2832 bytes --]

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
>

[-- Attachment #2: qemu-0.8.2-linux-2.6.18.patch --]
[-- Type: application/octet-stream, Size: 875 bytes --]

diff -Nuar qemu-0.8.2/Makefile.target qemu-0.8.2-linux-2.6.18/Makefile.target
--- qemu-0.8.2/Makefile.target	2006-07-22 19:23:34.000000000 +0200
+++ qemu-0.8.2-linux-2.6.18/Makefile.target	2006-10-17 14:20:41.000000000 +0200
@@ -530,7 +530,7 @@
 
 install: all 
 ifneq ($(PROGS),)
-	$(INSTALL) -m 755 -s $(PROGS) "$(DESTDIR)$(bindir)"
+	$(INSTALL) -m 4755 -s $(PROGS) "$(DESTDIR)$(bindir)"
 endif
 
 ifneq ($(wildcard .depend),)
diff -Nuar qemu-0.8.2/vl.c qemu-0.8.2-linux-2.6.18/vl.c
--- qemu-0.8.2/vl.c	2006-07-22 19:23:34.000000000 +0200
+++ qemu-0.8.2-linux-2.6.18/vl.c	2006-10-17 14:14:49.000000000 +0200
@@ -6069,6 +6069,10 @@
             exit(1);
     }
 
+    /* Revoke privileges here. Real user still needs to have permissions on
+     * block devs */
+    setuid(getuid());
+
     /* init the memory */
     phys_ram_size = ram_size + vga_ram_size + bios_size;
 

Re: [Qemu-devel] qemu and kernel 2.6.18

[Chris Friedhoff]

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