Containers Archive mirror
 help / color / mirror / Atom feed
From: Akihiro Suda <suda.kyoto@gmail.com>
To: Paul Moore <paul@paul-moore.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	linux-kernel@vger.kernel.org,  containers@lists.linux.dev,
	serge@hallyn.com, brauner@kernel.org,
	 akihiro.suda.cz@hco.ntt.co.jp
Subject: Re: [PATCH linux 0/3] [PATCH] userns: add sysctl "kernel.userns_group_range"
Date: Sat, 3 Jun 2023 06:02:30 +0900	[thread overview]
Message-ID: <CAG8fp8TN+DQu8kok7_PcxtK=7TTBJTYm60-Y9ZnH+Euf5n4xJQ@mail.gmail.com> (raw)
In-Reply-To: <CAHC9VhT_D9qc3Od-DTZ52q_7bySOX1FWLTXha_OJUyHK5woq5w@mail.gmail.com>

Thank you all for feedbacks,

> (Paul)

> Given the challenges around adding access controls to userns
> operations, have you considered using the LSM support that was added
> upstream last year?

I'll consider this.

> The relevant LSM hook can be found in commit
> 7cd4c5c2101c ("security, lsm: Introduce security_create_user_ns()"),
> and although only SELinux currently provides an access control
> implementation, there is no reason you couldn't add support for your
> favorite LSM, or even just a simple BPF LSM to enforce the group
> controls as you've described them here.

My intent is to provide an universal knob that works for both SELinux
distros and AppArmor distros.
So I guess I should try to use BPF LSM (and find out how its end-user
UX in the userspace can be simplified just like sysctl).

---
> (Christian)

> Yes. Please, no more sysctls...

I'll try to find another way, such as (BPF) LSM.

---
> (Eric)

> How does this functionally differ from what already exists
> user.max_user_namespaces?

My patch is not about the numbers of the UserNS, but about who is
permitted to create UserNS,
which can be a potential attack surface to pwn the root in the initial UserNS.

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

Yes, that's my goal.
The intent is to allow creating UserNS only for (semi-trusted) human
users who need to run unprivileged (aka rootless) containers.
Creating UserNS is expected to be prohibited for system daemon
accounts and human users who do not need (or who are not trusted
enough) to run containers.

This configuration should be more secure than just allowing everybody
to run unprivileged (aka rootless) containers, and also more secure
than just disabling UserNS and running everything as the root.

> 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?

In a child UserNS, the group_range file is expected to use the mapped
IDs, not the initial UserNS IDs.
(So, the range can't be just initialized with `.range = {0,
((gid_t)~0U) - 1}`. My patch v1 is wrong.)

> Paul are you aware that the LSM hook can not be used to achieve the
> objective of this patchset?

What would be an obstacle to using an LSM hook for this? (with an
addition of GID checks)

2023年6月2日(金) 23:50 Paul Moore <paul@paul-moore.com>:
>
> On Thu, Jun 1, 2023 at 9:41 PM Eric W. Biederman <ebiederm@xmission.com> wrote:
> > Paul Moore <paul@paul-moore.com> writes:
> > > On Thu, Jun 1, 2023 at 8:14 PM Eric W. Biederman <ebiederm@xmission.com> wrote:
> > >> Paul Moore <paul@paul-moore.com> writes:
> > >> >
> > >> > Given the challenges around adding access controls to userns
> > >> > operations, have you considered using the LSM support that was added
> > >> > upstream last year?  The relevant LSM hook can be found in commit
> > >> > 7cd4c5c2101c ("security, lsm: Introduce security_create_user_ns()"),
> > >>
> > >> Paul how have you handled the real world regression I reported against
> > >> chromium?
> > >
> > > I don't track chromium development.
> >
> > You have chosen to be the maintainer and I reported it to you.
>
> I just dug through all of the mail I've received from you over the
> past two (?) years, as well as checking the LSM archive on lore and I
> don't see any bug reports from you directed at the upstream LSM or
> SELinux code ... perhaps I missed something, do you have a pointer?
>
> Also, for the sake of clarification, I do not maintain any part of
> Chromium or Chrome OS.  I do maintain the upstream LSM, SELinux,
> audit, and labeled networking subsystems in the Linux Kernel as well
> as a couple of userspace packages.
>
> > >> Paul are you aware that the LSM hook can not be used to achieve the
> > >> objective of this patchset?
> > >
> > > /me shrugs
> >
> > [snip parts about performing a group id check]
>
> My comments here were only discussing the possibility of performing a
> group ID based access control check; I made no claims about the
> desirability of such a check, and I have no interest in rehashing our
> old debates.
>
> --
> paul-moore.com

  reply	other threads:[~2023-06-02 21:02 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 [this message]
2023-06-02  0:06 ` Eric W. Biederman

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='CAG8fp8TN+DQu8kok7_PcxtK=7TTBJTYm60-Y9ZnH+Euf5n4xJQ@mail.gmail.com' \
    --to=suda.kyoto@gmail.com \
    --cc=akihiro.suda.cz@hco.ntt.co.jp \
    --cc=brauner@kernel.org \
    --cc=containers@lists.linux.dev \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paul@paul-moore.com \
    --cc=serge@hallyn.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).