[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87v8g6bud8.fsf@email.froward.int.ebiederm.org>
Date: Thu, 01 Jun 2023 19:06:27 -0500
From: "Eric W. Biederman" <ebiederm@...ssion.com>
To: ~akihirosuda <akihirosuda@....sr.ht>
Cc: linux-kernel@...r.kernel.org, containers@...ts.linux.dev,
serge@...lyn.com, brauner@...nel.org, paul@...l-moore.com,
~akihirosuda <suda.kyoto@...il.com>,
akihiro.suda.cz@....ntt.co.jp
Subject: Re: [PATCH linux 0/3] [PATCH] userns: add sysctl
"kernel.userns_group_range"
~akihirosuda <akihirosuda@....sr.ht> writes:
> This sysctl limits groups who can create a new userns without
> CAP_SYS_ADMIN in the current userns, so as to mitigate potential kernel
> vulnerabilities around userns.
>
> The sysctl value format is same as "net.ipv4.ping_group_range".
>
> To disable creating new unprivileged userns, set the sysctl value to "1
> 0" in the initial userns.
>
> To allow everyone to create new userns, set the sysctl value to "0
> 4294967294". This is the default value.
>
> This sysctl replaces "kernel.unprivileged_userns_clone" that is found in
> Ubuntu [1] and Debian GNU/Linux.
>
> Link: https://git.launchpad.net/~ubuntu-
> kernel/ubuntu/+source/linux/+git/jammy/commit?id=3422764 [1]
>
> Signed-off-by: Akihiro Suda <akihiro.suda.cz@....ntt.co.jp>
How does this functionally differ from what already exists
user.max_user_namespaces?
Given that setns exists I don't see limiting creation of user namespaces
by group being meaningful, if your goal is to reduce the attack surface
of the kernel to mitigate potential kernel vulnerabilities.
How does this functionality interact with the use of setgroups in a user
namespace?
What is the value of a group_range inside of a newly created user
namespace? How does that work to maintain the policy you are trying to
implement?
Eric
Powered by blists - more mailing lists