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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAKD1Yr0ZXniXMyZ3WcWFsZ=UD9JJ+Bhv69meRrGuMEiN-_SugA@mail.gmail.com>
Date:	Wed, 7 May 2014 19:58:10 +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 Wed, May 7, 2014 at 6:24 PM, Hannes Frederic Sowa
<hannes@...essinduktion.org> wrote:
> I question the abstraction of using UIDs for matching routing rules.
> E.g. freebsd uses setfib[1] to alter the view of the routing table per
> process. E.g. an interface like ip rule exec (action ACTION)+ PROGRAM
> would be much nicer in combination with a prctl, maybe? I would much
> rather enjoy an interface not based on UIDs. Would something like that
> solve your initial problem?

So you're suggesting something that would still be an ip rule, but
would match a new identifier ("fibgroup") rather than the uid? I think
that would work, though obviously it's a much bigger change than what
I am proposing here.

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.

If you're proposing something not that's not an ip rule, then that
seems like a step backwards, because it won't allow the rich policy
allowed by processing rules in priority order, throw routes, FRA_GOTO,
etc.
--
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