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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 7 May 2014 12:59:17 +0900
From:	Lorenzo Colitti <lorenzo@...gle.com>
To:	David Miller <davem@...emloft.net>
Cc:	David Newall <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 Sat, May 3, 2014 at 4:24 AM, David Miller <davem@...emloft.net> wrote:
> > did that help clarify what I'm proposing here? Does this patch still
> > seem misguided to you even though its semantics match existing
> > functionality?
>
> I understand what you're trying to achieve, but it still leaves a very
> bad taste in my mouth.
>
> And I question whether you absolutely cannot get the desired source
> address set with appropriate adjustments to the netfilter config,
> netfilter can mangle the packet any way you desire it to so why can't
> it do so to the source address?

The problem is not that netfilter picks the wrong source address. The
problem is that it that address doesn't match the socket's source
address. The source address in the socket is selected by the initial
routing lookup (e.g., in tcp_v[46]_connect), but the packet source
address is from the output interface . So if the application calls
getsockname(), it will get an IP address that's not the one that is
actually being used to send its packets (and in fact is on a different
interface). This breaks applications that need end-to-end
connectivity. It also doesn't allow applications to select their
source address using things like bind(), IPV6_PKTINFO,
IPV6_ADDR_PREFERENCES,  etc.

This doesn't just affect the source address, it similarly affects any
other parameters that are taken from route lookups and stored in the
socket, such as MSS, initial cwnd / rwnd / RTO, etc. Some (like MSS)
can be fixed up with netfilter, but not all. Also, every connection
made through this scheme takes up conntrack state, is affected by
conntrack timeouts, etc.

Assuming you agree that this is sane use case, then I think UID-based
routing rules are a much cleaner way to do it than netfilter. The
kernel has all the information it needs to do this correctly, but
today we do not use that information in the initial lookup - we just
use it later on to do NAT. That breaks app expectations before the
packet even hits the wire, and that leaves a bad taste in my mouth.

I can see why we wouldn't want to add new rule types when things can
be done with netfilter. But I think that when it comes to making
routing decisions based on information that's in the socket structure
(i.e., from the application), those have to be made using routing
rules. For output packets, netfilter only gets to influence things too
late, so it can at best patch things up later.
--
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