re: Allow group ownership of TUN/TAP devices.

re: Allow group ownership of TUN/TAP devices.

[Michael Tokarev]

Hi.  Just noticed an old commit 8c644623fe7e41f59fe97cdf666cba3cb7ced7d8
dated Mon Jul 2 22:50:25 2007 -0700 that allows group ownership for
tun/tap devices.  Here's the comment:

    [NET]: Allow group ownership of TUN/TAP devices.

    Introduce a new syscall TUNSETGROUP for group ownership setting of tap
    devices. The user now is allowed to send packages if either his euid or
    his egid matches the one specified via tunctl (via -u or -g
    respecitvely). If both, gid and uid, are set via tunctl, both have to
    match.

Two questions:

1: why both has to match?  Is it really useful?
 (I understand it's a corner case, somehow)

2, and this is the main one: How about supplementary groups?

Here I have a valid usage case: a group of testers running various
versions of windows using KVM (kernel virtual machine), 1 at a time,
to test some software.  kvm is set up to use bridge with a tap device
(there should be a way to connect to the machine).  Anyone on that group
has to be able to start/stop the virtual machines.

My first attempt - pretty obvious when I saw -g option of tunctl - is
to add group ownership for the tun device and add a supplementary group
to each user (their primary group should be different).  But that fails,
since kernel only checks for egid, not any other group ids.

What's the reasoning to not allow supplementary groups and to only check
for egid?

Thanks!

/mjt

Re: Allow group ownership of TUN/TAP devices.

[Michael Tokarev]

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

Michael Tokarev wrote:
[]
> 2, and this is the main one: How about supplementary groups?
> 
> Here I have a valid usage case: a group of testers running various
> versions of windows using KVM (kernel virtual machine), 1 at a time,
> to test some software.  kvm is set up to use bridge with a tap device
> (there should be a way to connect to the machine).  Anyone on that group
> has to be able to start/stop the virtual machines.
> 
> My first attempt - pretty obvious when I saw -g option of tunctl - is
> to add group ownership for the tun device and add a supplementary group
> to each user (their primary group should be different).  But that fails,
> since kernel only checks for egid, not any other group ids.
> 
> What's the reasoning to not allow supplementary groups and to only check
> for egid?

Like this.

Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

Thanks!

/mjt


[-- Attachment #2: tun-allow-supplementary-groups.diff --]
[-- Type: text/x-patch, Size: 444 bytes --]

--- linux-2.6.28/drivers/net/tun.c.orig	2008-12-25 02:26:37.000000000 +0300
+++ linux-2.6.28/drivers/net/tun.c	2009-02-02 17:33:02.000000000 +0300
@@ -714,7 +714,7 @@ static int tun_set_iff(struct net *net, 
 		if (((tun->owner != -1 &&
 		      current->euid != tun->owner) ||
 		     (tun->group != -1 &&
-		      current->egid != tun->group)) &&
+		      !in_egroup_p(tun->group))) &&
 		     !capable(CAP_NET_ADMIN))
 			return -EPERM;
 	}

Re: Allow group ownership of TUN/TAP devices.

[David Miller]

From: Michael Tokarev <mjt@tls.msk.ru>
Date: Mon, 02 Feb 2009 17:44:34 +0300

> Michael Tokarev wrote:
> []
> > 2, and this is the main one: How about supplementary groups?
> > 
> > Here I have a valid usage case: a group of testers running various
> > versions of windows using KVM (kernel virtual machine), 1 at a time,
> > to test some software.  kvm is set up to use bridge with a tap device
> > (there should be a way to connect to the machine).  Anyone on that group
> > has to be able to start/stop the virtual machines.
> > 
> > My first attempt - pretty obvious when I saw -g option of tunctl - is
> > to add group ownership for the tun device and add a supplementary group
> > to each user (their primary group should be different).  But that fails,
> > since kernel only checks for egid, not any other group ids.
> > 
> > What's the reasoning to not allow supplementary groups and to only check
> > for egid?
> 
> Like this.
> 
> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

Seems reasonable, applied, thanks.

Re: Allow group ownership of TUN/TAP devices.

[Guido Günther]

On Mon, Feb 02, 2009 at 05:18:53PM +0300, Michael Tokarev wrote:
[..snip..] 
> My first attempt - pretty obvious when I saw -g option of tunctl - is
> to add group ownership for the tun device and add a supplementary group
> to each user (their primary group should be different).  But that fails,
> since kernel only checks for egid, not any other group ids.
Since others tripped on this it might make sense to change it to also
check supplementary groups. However I don't think changing the existing
syscall is an option since it might allow users to access tun/tap
devices on existing systems that weren't allowed to do so before (which
might be a security problem).
Cheers,
 -- Guido

Re: Allow group ownership of TUN/TAP devices.

[Michael Tokarev]

[Again, resurrecting an old thread...
  lkml added -- this is a policy issue, so to say]

Guido Günther wrote at Thu, 5 Feb 2009 11:54:57 +0100:
> On Mon, Feb 02, 2009 at 05:18:53PM +0300, Michael Tokarev wrote:
> [..snip..] 
>> My first attempt - pretty obvious when I saw -g option of tunctl - is
>> to add group ownership for the tun device and add a supplementary group
>> to each user (their primary group should be different).  But that fails,
>> since kernel only checks for egid, not any other group ids.

It's a bit worse than that.  I.e., there's exactly 2 problems here.

First, currently tun driver only checks primary gid and not any
supplementary gids (this is what my one-line patch addressed).

And second, if both gid and uid is specified for the given tun
device, BOTH should match.  I.e, I can be "owner"(*) of the device
in question, but if my current gid does not match, I still can't
use it.  This one is interesting: currently, one can grant a tun
device to a given "incarnation" of an uid, that is, suppose we've
two processes running under the same uid but with different gids -
this way, I can grant the device to only one of them.  But here,
why to grant to uid anyway, just use that gid.. I think ;)

(*) note the quotes around "owner" here because, unlike with, say,
files, I can't do anything I want with the network device, I only
have very limited set of operations.

> Since others tripped on this it might make sense to change it to also
> check supplementary groups. However I don't think changing the existing
> syscall is an option since it might allow users to access tun/tap
> devices on existing systems that weren't allowed to do so before (which
> might be a security problem).

And this is the question which's the reason why I added Cc LKML.

My point of view is that it's a bug in original design, it was done
not so long ago (around mid-2007, well, 2+ years isn't that short
anymore, right?), this feature isn't used much currently (because
it's less known than, say, user ownership and because of this very
bug), and because fixing it by introducing another mechanism nearby
is even more ugly (IMHO anyway).

The lack of (wide) usage (or anyway, I think that this feature is
not widely used) -- currently, due to the requirement that it must
be primary group, it's almost impossible to use.  A device gets
granted to a user instead, or the group in question becomes his
primary group, without granting it to others.  In most cases anyway.
This is in addition to the fact that group ownership for a net
device isn't very useful to begin with, because it's not intended
for "collective" use in the first place.

But the question remains -- what to do with this mess.

I almost forgot about this issue, -- I added the patch to the
local kernel package and it worked since.  But today I tried
to compile 2.6.29, the patch didn't apply so I skipped it the
first try, and almost immediately trapped to this issue again,
because my scripts and my kvm stuff stopped working... ;)

Thanks!

/mjt