From: "Eric W. Biederman" <ebiederm@xmission.com>
To: ~akihirosuda <akihirosuda@git.sr.ht>
Cc: linux-kernel@vger.kernel.org, containers@lists.linux.dev,
serge@hallyn.com, brauner@kernel.org, paul@paul-moore.com,
~akihirosuda <suda.kyoto@gmail.com>,
akihiro.suda.cz@hco.ntt.co.jp
Subject: Re: [PATCH linux 0/3] [PATCH] userns: add sysctl "kernel.userns_group_range"
Date: Thu, 01 Jun 2023 19:06:27 -0500 [thread overview]
Message-ID: <87v8g6bud8.fsf@email.froward.int.ebiederm.org> (raw)
In-Reply-To: <168547265011.24337.4306067683997517082-0@git.sr.ht> (akihirosuda@git.sr.ht's message of "Tue, 30 May 2023 18:50:50 +0000")
~akihirosuda <akihirosuda@git.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@hco.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
prev parent reply other threads:[~2023-06-02 0:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-30 18:50 [PATCH linux 0/3] [PATCH] userns: add sysctl "kernel.userns_group_range" ~akihirosuda
2023-05-30 11:34 ` [PATCH linux 3/3] " ~akihirosuda
2023-05-31 4:20 ` kernel test robot
2023-05-30 14:42 ` [PATCH linux 1/3] net/ipv4: split group_range logic to kernel/group_range.c ~akihirosuda
2023-05-30 17:31 ` [PATCH linux 2/3] group_range: allow GID from 2147483648 to 4294967294 ~akihirosuda
2023-05-30 21:58 ` [PATCH linux 0/3] [PATCH] userns: add sysctl "kernel.userns_group_range" Paul Moore
2023-05-31 7:50 ` Christian Brauner
2023-06-02 0:14 ` Eric W. Biederman
2023-06-02 1:01 ` Paul Moore
2023-06-02 1:41 ` Eric W. Biederman
2023-06-02 14:50 ` Paul Moore
2023-06-02 21:02 ` Akihiro Suda
2023-06-02 0:06 ` Eric W. Biederman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87v8g6bud8.fsf@email.froward.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=akihiro.suda.cz@hco.ntt.co.jp \
--cc=akihirosuda@git.sr.ht \
--cc=brauner@kernel.org \
--cc=containers@lists.linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=serge@hallyn.com \
--cc=suda.kyoto@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).