# iptables and --gid-owner

## mani001

I'm trying to block a group by means of iptable. I made a rule:

```

iptables -A OUTPUT -o "eth0" -m owner --gid-owner 35 -j DROP

```

This is the only one rule I've got in the output chain, and the default policy is ACCEPT

Then, for testing, I did:

```

manu@aguarrio /tmp $ cp /usr/bin/firefox ./firefox-tmp

manu@aguarrio /tmp $ chown manu:games firefox-tmp

manu@aguarrio /tmp $ ls -l firefox-tmp

-rwxr-xr-x  1 manu games 376 dic 29 19:40 firefox-tmp*

```

However, the new firefox-tmp is still able to connect to internet. Why?

My kernel is 2.6.13-gentoo-r5.

----------

## jamapii

Some owner checking features have been removed because they've never been SMP/preempt-safe. I don't remember if gid is affected, but there should be an error message in syslog or the iptables output.

If the feature is still present, the feature checks the (effective or real? I don't know) group id for the process. That's the user who called it, not the one who owns the binary, unless the setuid/setgid bit is set on the binary.

If you "chmod g+s" the binary, you can change the effective gid for the process. But this only works for the real binary, it doesn't work for a shell script.

----------

## MrUlterior

 *mani001 wrote:*   

> I'm trying to block a group by means of iptable. I made a rule:
> 
> ```
> 
> iptables -A OUTPUT -o "eth0" -m owner --gid-owner 35 -j DROP
> ...

 

AFAIK, you shouldn't have the quotes around the interface name, so change that to:

```

iptables -A OUTPUT -o eth0 -m owner --gid-owner 35 -j DROP

```

I use this currently on my firewall, I suggest using REJECT instead of DROP .. it seems to make the apps fail better & quicker.

----------

## MrUlterior

 *jamapii wrote:*   

> Some owner checking features have been removed because they've never been SMP/preempt-safe. I don't remember if gid is affected, but there should be an error message in syslog or the iptables output.
> 
> 

 

Where did you hear this? I've been running iptables SMP with no probs. I did a quick google & found nothing on the subject.

----------

## mani001

The quotes around eth0 don't make any difference. The rule is well built. I can see it if I do "iptables -L".

 *Quote:*   

> 
> 
> Some owner checking features have been removed because they've never been SMP/preempt-safe. I don't remember if gid is affected, but there should be an error message in syslog or the iptables output. 
> 
> 

 

You are right: some checking features have been removed, but I think is in kernel 2.6.14. I know in 2.6.14 there is no --cmd-owner for example... I know nothing about --gid-owner. Anyway, it doesn't affect kernel 2.6.13.

 *Quote:*   

> 
> 
> If the feature is still present, the feature checks the (effective or real? I don't know) group id for the process. That's the user who called it, not the one who owns the binary, unless the setuid/setgid bit is set on the binary. 
> 
> 

 

It checks the effective groud id, according to man. I tried "chmod g+s wget" (I don't know whether it matters but firefox was a script) after "chown me:games wget" , but nothing... I also tried "newgrp games", which I have just found out, that changes your current group id.. and no way. 

If you have any other idea...

Thanks for your replies anyway.

----------

## jamapii

 *MrUlterior wrote:*   

> Where did you hear this? I've been running iptables SMP with no probs. I did a quick google & found nothing on the subject.

 

In a kernel >= 2.6.14 and possibly >= 2.4.31 I think, see the file /usr/src/linux/net/ipv4/netfilter/ipt_owner.c

Only UID and GID check are implemented. I don't remember the exact google keywords, but try some words and phrases (error message) you find in this file. There is a reverse lookup involved from file descriptor to process, which is inevitable because processes can share file descriptors (correct?). The reverse lookup requires locking that can lead either to deadlocks or reading nonsense data (if locking is optimized away), and implementing the locking correctly would require a change in all of the kernel and cause a performance hit. (if I understand it correctly)

--gid-owner is still implemented, causes no problems and I think it's a very good idea that should work. 

Maybe you can add a few printk lines to the above mentioned file, recompile, try it and watch syslog. (this would be my only idea at this point)

----------

