linux-kernel - Re: [PATCH] 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: <66ror6q2-7pq2-os23-rq8r-8426ppr6pnps@vanv.qr>
Date: Mon, 7 Apr 2025 12:56:33 +0200 (CEST)
From: Jan Engelhardt <ej@...i.de>
To: Florian Westphal <fw@...len.de>
cc: lvxiafei <xiafei_xupt@....com>, "David S. Miller" <davem@...emloft.net>, 
    Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, 
    Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, 
    Pablo Neira Ayuso <pablo@...filter.org>, 
    Jozsef Kadlecsik <kadlec@...filter.org>, lvxiafei <lvxiafei@...setime.com>, 
    netdev@...r.kernel.org, linux-kernel@...r.kernel.org, 
    netfilter-devel@...r.kernel.org, coreteam@...filter.org
Subject: Re: [PATCH] netfilter: netns nf_conntrack: per-netns
 net.netfilter.nf_conntrack_max sysctl


On Monday 2025-04-07 12:13, Florian Westphal wrote:
>lvxiafei <xiafei_xupt@....com> wrote:
>> The modification of nf_conntrack_max in one netns
>> should not affect the value in another one.
>
>nf_conntrack_max can only be changed in init_net.
>
>Given the check isn't removed:
>   /* Don't allow non-init_net ns to alter global sysctls */
>   if (!net_eq(&init_net, net)) {
>       table[NF_SYSCTL_CT_MAX].mode = 0444;
>
>... this patch seems untested?
>
>But, removing this check would allow any netns to consume
>arbitrary amount of kernel memory.
>
>How do you prevent this?

By inheriting an implicit limit from the parent namespace somehow.
For example, even if you set the kernel.pid_max sysctl in the initial
namespace to something like 9999, subordinate namespace have
kernel.pid_max=4million again, but nevertheless are unable to use
more than 9999 PIDs. Or so documentation the documentation
from commit d385c8bceb14665e935419334aa3d3fac2f10456 tells me
(I did not try to create so many processes by myself).

A similar logic would have to be applied for netfilter sysctls
if they are made modifiable in subordinate namespaces.