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] [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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ