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

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

On Mon, May 12, 2014 at 6:45 AM, Hannes Frederic Sowa
<hannes@...essinduktion.org> wrote:
>> It would require defining a new identifier, figuring out what its
>> semantics are, setting it when socket objects are created, attaching
>> it to sockets across accept/fork, etc. Userspace code would have to be
>> update it to set it on processes (whereas the uid is already dealt
>> with by existing tools), etc.
>
> That was my idea, yes. Having some kind of opaque identifier with
> user-friendly names a la /etc/iproute2/rt_tables which can be used in ip
> rule matches.
>
> I see, it would require very heavy lifting, but in the end seems to be
> more user-friendly to me than uids.

Well, I don't know. Today we have an iptables module in tree that does
UID matching, which means that presumably people do find it useful. In
addition to the Android use case there seem to be other people doing
it as well [1][2][3]. On the other hand, we don't have a similar one
for PIDs or a generic "fib grouo". nftables meta seems to support UID
and gid, but not PID.

For people that currently use the socket owner to do routing, this
patch is a strictly better way to do it, because it doesn't have any
of the drawbacks of NAT (information in the socket structures that
doesn't correspond to reality; more conntrack state; NAT breaking
end-to-end; etc.).

Whether a new fibgroup option would serve these use cases better is
hard to say. If what people want to do is per-process, then perhaps an
opaque fibgroup is better. But if what they actually want to do is
per-user, then if you implement fibgroups you still have to build
machinery in userspace to make sure that each user's processes got put
into the right fib group.

[1] http://blog.sebastien.raveau.name/2009/04/per-process-routing.html
[2] http://arstechnica.com/civis/viewtopic.php?f=16&t=1195455
[3] http://www.niftiestsoftware.com/2011/08/28/making-all-network-traffic-for-a-linux-user-use-a-specific-network-interface/
--
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