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: <1399844745.13956.116157949.32873A56@webmail.messagingengine.com>
Date:	Sun, 11 May 2014 14:45:45 -0700
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Lorenzo Colitti <lorenzo@...gle.com>
Cc:	David Miller <davem@...emloft.net>,
	David Newall <davidn@...idnewall.com>, 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 3:58, Lorenzo Colitti wrote:
> 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.

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. But I guess task_struct is something
like sk_buff, where you need to find very good arguments to expand it.

Maybe something like cgroup/net_cls.classid would be possible, but I am
not familar on how to interact with cgroups internally and don't know
how much work that would be (and if more network cgroup interaction is
actually desirable).

> 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.

Agreed.

Bye,

  Hannes
--
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