netdev - Re: [RFC net-next 0/4] Support UID range routing.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 29 Apr 2014 04:01:05 +0900
From:	Lorenzo Colitti <lorenzo@...gle.com>
To:	David Miller <davem@...emloft.net>
Cc:	davidn@...idnewall.com,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	JP Abgrall <jpa@...gle.com>
Subject: Re: [RFC net-next 0/4] Support UID range routing.

On Tue, Apr 29, 2014 at 1:58 AM, David Miller <davem@...emloft.net> wrote:
> There is absolutely no such thing as the UID of a socket.

Sorry - perhaps I should have said "socket creator" or "socket owner".
Basically, what this patch calls "UID" is what the xt_owner module and
xt_LOG iptables modules consider to be the "owner" of a socket, what
nfqueue presents as the user ID, what shows up in
/proc/net/{udp,tcp,raw} in the "uid" column, etc. In most cases this
is the effective UID that made the call to socket() or accept().

This patch allows using that concept in routing. This can be done
today with "iptables -m owner --uid-owner 12345 -j MARK --set-mark
0xbeef; ip rule from fwmark 0xbeef lookup 100", but that has the
limitations I set out in my original message (e.g., incorrect source
address).

> And in software interrupt context, sending TCP ACKs for example, at
> best you have just the socket.  There is no appropriate UID to choose
> in such situations.

For as long as a kernel socket has a corresponding userspace socket,
the kernel socket has a pointer to the userspace socket object
(sk->sk_socket), which has the owner UID, right? So that information
is still accessible even outside process context. It's true that when
the userspace socket is closed that information goes away, but in
theory, it could be written back to the kernel socket in sock_orphan.

> I absolutely do not want to see a feature like this added to the tree,
> as it exemplifies a rather deep misunderstanding of how the hierarchy
> of networking stack objects are arranged and relate to eachother.

The examples I cite above are all in the tree. Do you consider them to
be misguided? In particular, the semantics of the iptables owner match
module seem quite similar to me - it allows making decisions
(including routing decisions) on a packet based on the socket owner.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html