Re: CAP_NET_ADMIN (was Re: [Qemu-devel] Two quick requests.)
Have a look here with links and a description: http://www.friedhoff.org/fscaps.html http://www.friedhoff.org/fscaps.html#Qemu Serges patch is in the mm tree. Chris On Sat, 10 Feb 2007 15:11:00 + Paul Brook [EMAIL PROTECTED] wrote: Is there any way around this? I expected to be able to configure capabilities for executables in the filesystem, but it appears there are serious problems with that concept so the kernel doesn't support it. Use tunctl to create the device. Paul ___ 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
Re: [Qemu-devel] qemu and kernel 2.6.18
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.0
+0200
+++ linux-2.6.18/drivers/net/tun.c 2006-10-02 09:21:52.0
+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
Re: [Qemu-devel] qemu and kernel 2.6.18
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.0 +0200
+++ linux-2.6.18/drivers/net/tun.c 2006-10-02 09:21:52.0 +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
Re: [Qemu-devel] qemu and kernel 2.6.18
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.0 +0200
+++ linux-2.6.18/drivers/net/tun.c 2006-10-02 09:21:52.0 +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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
[EMAIL PROTECTED]
2.6.18-tun-without-cap_net_admin-capability.patch.bz2
Description: Binary data
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
