linux-kernel - Re: [PATCH 00/13] SCTP: Enable netns

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]

Message-ID: <87mx27rig7.fsf@xmission.com>
Date:	Mon, 06 Aug 2012 11:20:08 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Jan Ariyasu <jan.ariyasu@...il.com>
Cc:	Vlad Yasevich <vyasevich@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	linux-sctp@...r.kernel.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, Jan Ariyasu <jan.ariyasu@...com>
Subject: Re: [PATCH 00/13] SCTP: Enable netns

Jan Ariyasu <jan.ariyasu@...il.com> writes:

> The following set of patches enable network-namespaces for the SCTP protocol.
>
> The multitude of global parameters are stored in a net_generic
> structure, and the bulk of the patches enable the protocol to access
> the parameters on a per-namespace basis.  The first five patches
> enable netns handling of the protocol, procfs and sysfs.

I am going to do something to muddy the waters here, that I had hoped to
avoid when I saw your patchset.

A few weeks ago I wanted to play with sctp and also made a network
namespace enabled version.  I am not deeply attached to my changes,
however when comparing the differences I realized that your code fails
to make the lookup of associations per network namespace.

Given that we only have source and destination port to lookup
assoications by this almost guarantees one network namespace can
accidentially use the association of another network namespace meerly
by reusing the same ports.

The downside with my version is that it does not make all of the sctp
tunables per network namespace the way yours does, but making all of
the tunables per network namespace should be straight forward from
my base.

My patchset also misses some nice to haves like making the association
id allocation per network namespace.  It is not important for
correctness of the code but it might allow an information leak between
namespaces.

So Jan I am going to send my patchset and hopefully you can rebase your
changes to make all of the tunables per network namespace on top of
mine.

Since my patchset is half the size of your I think that is the most
reasonable way to go.

Eric

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