Re: [PATCH linux 0/3] [PATCH] userns: add sysctl "kernel.userns_group_range"

[Akihiro Suda]

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@xxxxxxxxxxxxxx>:
>
> On Thu, Jun 1, 2023 at 9:41 PM Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote:
> > Paul Moore <paul@xxxxxxxxxxxxxx> writes:
> > > On Thu, Jun 1, 2023 at 8:14 PM Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote:
> > >> Paul Moore <paul@xxxxxxxxxxxxxx> 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