linux-kernel - Re: [GIT PULL] LSM patches for v6.1

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] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 5 Oct 2022 11:54:32 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     Paul Moore <paul@...l-moore.com>,
        linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] LSM patches for v6.1

On Wed, Oct 5, 2022 at 5:39 AM Eric W. Biederman <ebiederm@...ssion.com> wrote:
>
> We already have /proc/sys/user/max_user_namespaces.  It is a per userns
> control so you can run it in as fine grain as you like.  A little
> cumbersome perhaps but real.

It's not that it's cumbersome.

It's that it is *USELESS*.

Sure, it limits the memory footprint of somebody who does the
fork-bomb equivalent of user namespaces, but that's the least of the
problems.

Just think of normal users. They'd want a limited number of user
namespaces for things like sandboxing (whether google chrome or
whatever).

So distros do want to allow people a few of them.

But they want to be able to do so in a *controlled* manner. Not a "ok,
this user can create five user namespaces and do whatever they want in
them". Because we've had the issues where some kernel part has gotten
things wrong, and thought "local NS root means root" or similar.

So it's not about the number of namespaces. AT ALL. It's about *who*
and *what* does them.

> I don't know.  I tried to have the conversation and Paul shut it down.

I really get the feeling that the problem here is that you're not even
acknowledging the whole issue to begin with, since you mention that
"max_user_namespaces" not once, but twice in the email.

> It would be the easiest thing in the world in security_capable to
> ask is this a trusted app, if not the answer is no.

Isn't this *literally* what security_create_user_ns() would basically be doing?

IOW, letting the LSM just say "this app is trusted to create a new
user namespace".

And that is what the LSM model is literally designed for. Because the
kernel doesn't inherently know "I trust this app". It doesn't know the
difference between "google-chrome" and "l33t-crack3r". It needs some
kind of external set of rules.

See?

               Linus