netfilter buglog - Aug 2013 - [Bug 847] New: Owner matching fails on listening socket

https://bugzilla.netfilter.org/show_bug.cgi?id=847

           Summary: Owner matching fails on listening socket
           Product: netfilter/iptables
           Version: unspecified
          Platform: x86_64
        OS/Version: Debian GNU/Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ip_tables (kernel)
        AssignedTo: netfilter-buglog at lists.netfilter.org
        ReportedBy: phil at sanewall.org
   Estimated Hours: 0.0


It seems the netfilter matching of socket owner by UID has changed between
kernel v3.2 and v3.10.

In 3.2 the owner would be matched whether the connection was initiated
from the firewall host or from the remote host.

In 3.10 the the UID is matched only when the connection is initiated from
the firewall host. The UID associated with the socket appears to not be
that of the process which is listening for connections.

Error results
*************
Tested were the wheezy and wheezy-backports kernels:
  3.2.0-4-amd64
and:
  3.10-0.bpo.2-amd64

Both with iptables v1.4.14

This was originally reported to me between two hosts, but works equally
well on the loopback device.

Using a single user for both listener and connector, and starting with
an empty firewall with everything set to ACCEPT:

  $ id -u
  1000

Test 1a - Works on both 3.2 and 3.10
------------------------------------
Verify connection without any firewall rules.

Start a listener on port 8889 and start a connection from source
port 8888.

Connection established and data flows.

  $ nc -l -p 8889         | nc -p 8888 127.0.0.1 8889
                          | I can send data!
  I can send data!        |
                          | ^C
Test 1b - Works on both 3.2 and 3.10
------------------------------------
Verify connection without any firewall rules.

Start a listener on port 8888 and start a connection from source
port 8889.

Connection established and data flows.

  $ nc -l -p 8888         | nc -p 8889 127.0.0.1 8888
                          | I can still send data!
  I can still send data!  |
                          | ^C

Setup firewall rule
-------------------
A single a rule which should stop any TCP packets from source port 8888
by our uid.

  sudo iptables -t filter -A OUTPUT -p tcp --sport 8888 \
                    -m owner --uid-owner 1000 -j REJECT


Test 2a - works on both 3.2 and 3.10
-----------------------------------
Verify packets blocked by firewall rule.

Start a listener on port 8889 and start a connection from source
port 8888.

Connection refused because our SYN packet is rejected.

$ nc -l -p 8889         | nc -p 8888 127.0.0.1 8889
                        | (UNKNOWN) [127.0.0.1] 8889 (?) : Connection refused
^C                      |


Test 2b - works on 3.2 but not 3.10
-----------------------------------
Verify packets blocked by firewall rule.

Start a listener on port 8888 and start a connection from source
port 8889.

3.2: connection prevented (SYN ACK dropped)

$ nc -l -p 8888         | $ nc -p 8889 127.0.0.1 8888
                        | ^C (gave up)

3.10: can still connect and send data

$ nc -l -p 8888         | $ nc -p 8889 127.0.0.1 8888
                        | Still sending...!
Still sending...!       |
                        | ^C

Extra Info
**********
There is only one commit to in the owner matching code:
  git log v3.2..v3.10 -- net/netfilter/xt_owner.c

(which was appplied for v3.7).

commit 26711a791effbea125fea4284f4d1c4fa8f7bc73
Author: Eric W. Biederman <ebiederm at xmission.com>
Date:   Thu Feb 2 17:33:59 2012 -0800

    userns: xt_owner: Add basic user namespace support.

    - Only allow adding matches from the initial user namespace
    - Add the appropriate conversion functions to handle matches
      against sockets in other user namespaces.

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=847

phil at sanewall.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|enhancement                 |normal

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=847

Phil Oester <netfilter at linuxace.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |netfilter at linuxace.com

--- Comment #1 from Phil Oester <netfilter at linuxace.com> 2013-08-27
01:32:15 CEST ---
First, please use ports that don't differ by only one digit in your
examples.
Note how I used 7777 vs 8888 below, which make spotting the difference much
easier.

Anyhow - seems to work fine for me in 3.10+:

# uname -r
3.10.0+

# iptables -V
iptables v1.4.18

# iptables -A OUTPUT -p tcp --sport 8888 -m owner --uid-owner 1000 -j REJECT


[phil at linuxace ~]$ id
uid=1000(phil) gid=1000(phil) groups=1000(phil)

[phil at linuxace ~]$ echo hi | nc -p 8888 bathroom.mit.edu 79
Ncat: Connection refused.

[phil at linuxace ~]$ echo hi | nc -p 7777 bathroom.mit.edu 79    
Random Hall Bathroom Server v2.1
...

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=847

--- Comment #2 from phil at sanewall.org 2013-08-27 08:27:04 CEST ---
Yes, it works fine when the uid is establishing the connection. It fails when
the uid is listening.

Host 1

# sudo iptables -A OUTPUT -p tcp -m owner --uid-owner 1000 -j REJECT

pdw at compaq:~$ echo hi | nc bathroom.mit.edu 79
nw61-310-8.mit.edu [18.243.1.73] 79 (finger) : Connection refused
pdw at compaq:~$ echo hi | nc -l -p 8888

Host 2
dell:~ bob$ echo "ho" | nc compaq 8888

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=847

--- Comment #3 from Phil Oester <netfilter at linuxace.com> 2013-08-27
22:29:06 CEST ---
Confirmed.  Problematic commit is 90ba9b19 (tcp: tcp_make_synack() can use
alloc_skb()).  Discussing options.

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.

https://bugzilla.netfilter.org/show_bug.cgi?id=847

Phil Oester <netfilter at linuxace.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #4 from Phil Oester <netfilter at linuxace.com> 2013-09-01
16:58:37 CEST ---
This was fixed in commit eb8895deb (tcp: tcp_make_synack() should use
sock_wmalloc).  It should appear in 3.11 and -stable series kernels. 
Whitespace damaged version below:

--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2670,7 +2670,7 @@ struct sk_buff *tcp_make_synack(struct sock *sk, struct
dst_entry *dst,
        int tcp_header_size;
        int mss;

-       skb = alloc_skb(MAX_TCP_HEADER + 15, sk_gfp_atomic(sk, GFP_ATOMIC));
+       skb = sock_wmalloc(sk, MAX_TCP_HEADER + 15, 1, GFP_ATOMIC);
        if (unlikely(!skb)) {
                dst_release(dst);
                return NULL;


Closing.

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.