netdev - Re: [PATCH V2] netfilter: netns nf_conntrack: per-netns net.netfilter.nf_conntrack

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: <20250408132854.GA5425@breakpoint.cc>
Date: Tue, 8 Apr 2025 15:28:54 +0200
From: Florian Westphal <fw@...len.de>
To: lvxiafei <xiafei_xupt@....com>
Cc: fw@...len.de, coreteam@...filter.org, davem@...emloft.net,
	edumazet@...gle.com, horms@...nel.org, kadlec@...filter.org,
	kuba@...nel.org, linux-kernel@...r.kernel.org,
	lvxiafei@...setime.com, netdev@...r.kernel.org,
	netfilter-devel@...r.kernel.org, pabeni@...hat.com,
	pablo@...filter.org
Subject: Re: [PATCH V2] netfilter: netns nf_conntrack: per-netns
 net.netfilter.nf_conntrack_max sysctl

lvxiafei <xiafei_xupt@....com> wrote:
> This modification can make nf_conntrack_max support
> the netns level to set the size of the connection
> tracking table, and more flexibly limit the connection
> tracking of each netns. For example, the initial user ns
> has a default value (=max_factor*nf_conntrack_htable_size).
> The nf_conntrack_max when netns 1 and netns 2 are created
> is the same as the nf_conntrack_max in the initial user ns.
> You can set it to netns 1 1k and netns 2 2k without
> affecting each other.

Netns 2 can also set it to 2**31 and cause machine go OOM.

> If you are worried that different netns may exceed the
> initial user limit and memory limit when setting,
> apply max = min(init_net->max, net->max), the value in
> netns is not greater than init_net->max, and the new
> maximum memory consumption <= the original maximum memory
> consumption, which limits memory consumption to a certain
> extent.

That was one of the suggestions that I see how one could have
tunable pernet variable without allowing netns2 go haywire.

> However, this will bring several problems:
> 
> 1. Do not allow nf_conntrack_max in other netns to be greater
> than nf_conntrack_max of the initial user. For example, when
> other netns carry north-south traffic, the actual number of
> connection tracking is greater than that of the initial user.

Sure.

> 2. If nf_conntrack_max of the initial user is increased, the
> maximum memory consumption will inevitably increase by n copies

How is that different to current state of affairs?

> 3. If nf_conntrack_max of the initial user is reduced, will
> the existing connections in other netns be affected?

No, but new ones will be blocked until its below init_net limit again.