linux-kernel - Re: [patch -mm] net namespace: empty framework

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:	Thu, 23 Nov 2006 12:05:10 +0300
From:	Dmitry Mishin <dim@...nvz.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Cedric Le Goater <clg@...ibm.com>,
	Daniel Lezcano <dlezcano@...ibm.com>,
	Kirill Korotaev <dev@...nvz.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...l.org>, netdev@...r.kernel.org
Subject: Re: [patch -mm] net namespace: empty framework

On Wednesday 22 November 2006 20:53, Eric W. Biederman wrote:
> Cedric Le Goater <clg@...ibm.com> writes:
> >> no problem here, but I think we will need another one,
> >> or some smart way to do the network isolation (layer 3)
> >> for the network namespace (as alternative to the layer 2
> >> approach) ...
> >
> > My feeling (Dmitry and Daniel can correct me) is that it will be
> > addressed with an unshare-like flag : NETNS2 and NETNS3.
> >
> >> as they are both complementary in some way, I'm not sure
> >> a single space will suffice ...
> >
> > hmm, so you think there could be a 2 differents namespaces
> > for network to handle layer 2 or 3. Couldn't that be just a sub part
> > of net_namespace.
>
> The justification is performance and a little on the simplicity side.
>
> My personal feel is still that layer 3 is something easier done
> as a new kind of table in an iptables type infrastructure.  And in
> fact I believe if done that way would capture do what 90%+ of what
> all of the iptables rules do.  So it might be a nice firewalling speed up.
Two points about solution using netfilter infrastructure:
1) Conntracks and dependant modules are called with the highest priority and 
will require, that skb context will be the same in input and output chains, 
else it will be a good place for bugs. So, we should change context before it 
will be marked by conntracks;
2) This solution has worse performance in comparison with Daniel's solution 
due to additional lookup of context by ip addr.

>
> I don't think the layer 3 idea where you just do bind filter fits
> the namespace concept very well.
>
> Eric

-- 
Thanks,
Dmitry.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/