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: <874noflrzd.fsf@xmission.com>
Date:	Mon, 06 Aug 2012 12:50:46 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Vlad Yasevich <vyasevich@...il.com>
Cc:	Jan Ariyasu <jan.ariyasu@...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

Vlad Yasevich <vyasevich@...il.com> writes:

> Hi Eric
>
> Associations are looked up by ports, but then verifyed by addresses.
> Also, associations belong to sockets and simply validating the socket
> namespace should be sufficient.

True.  Your set of patches isn't quite as likely to malfunction as it
looked at first glance.  It requires address reuse which happens accross
namespaces but not too frequently.

As for validating the socket namespace I agree that is the fix and my
patchset winds up doing it.

>> 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.
>
> Hmm.. this one might be nice to have not from the perspective of leak,
> but from resource limitation.  Without this, once the id space is
> global is can be exhausted faster.

It takes a lot of associtations to exhaust the id space, but I have no
fundamental problems problems with the id allocation being per
namespace.  I had actually overlooked the local association id when I
did my patches.   After looking it became clear that making the
association id global was not necessary so I left it.

The sctp association id is a strange beast.  My personal inclination is
that the sctp association id really ought to be per sctp socket, but I
have not looked enough at the sctp userspace API to see if that works in
practice.  Shrug.

Mostly I am in favor of simple and correct.

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/