Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Eric W. Biederman" <ebiederm@xmission.com>
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     Frederick Lawler <fred@cloudflare.com>, kpsingh@kernel.org,
        revest@chromium.org, jackmanb@chromium.org, ast@kernel.org,
        daniel@iogearbox.net, andrii@kernel.org, kafai@fb.com,
        songliubraving@fb.com, yhs@fb.com, john.fastabend@gmail.com,
        jmorris@namei.org, serge@hallyn.com,
        stephen.smalley.work@gmail.com, eparis@parisplace.org,
        shuah@kernel.org, brauner@kernel.org, casey@schaufler-ca.com,
        bpf@vger.kernel.org, linux-security-module@vger.kernel.org,
        selinux@vger.kernel.org, linux-kselftest@vger.kernel.org,
        linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
        kernel-team@cloudflare.com, cgzones@googlemail.com,
        karl@bigbadwolfsecurity.com, tixxdz@gmail.com,
        Paul Moore <paul@paul-moore.com>
References: <20220815162028.926858-1-fred@cloudflare.com>
        <CAHC9VhTuxxRfJg=Ax5z87Jz6tq1oVRcppB444dHM2gP-FZrkTQ@mail.gmail.com>
Date:   Wed, 17 Aug 2022 10:07:50 -0500
In-Reply-To: <CAHC9VhTuxxRfJg=Ax5z87Jz6tq1oVRcppB444dHM2gP-FZrkTQ@mail.gmail.com>
        (Paul Moore's message of "Tue, 16 Aug 2022 17:51:12 -0400")
Message-ID: <8735dux60p.fsf@email.froward.int.ebiederm.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [PATCH v5 0/4] Introduce security_create_user_ns()
Precedence: bulk

>
> I just merged this into the lsm/next tree, thanks for seeing this
> through Frederick, and thank you to everyone who took the time to
> review the patches and add their tags.
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm.git next

Paul, Frederick

I repeat my NACK, in part because I am being ignored and in part
because the hook does not make technical sense.


Linus I want you to know that this has been put in the lsm tree against
my explicit and clear objections.

My request to talk about the actual problems that are being address has
been completely ignored.

I have been a bit slow in dealing with this conversation because I am
very much sick and not on top of my game, but that is no excuse to steam
roll over me, instead of addressing my concerns.


This is an irresponsible way of adding an access control to user
namespace creation.  This is a linux-api and manpages level kind of
change, as this is a semantic change visible to userspace.  Instead that
concern has been brushed off as different return code to userspace.

For observably this is a terrible LSM interface because there is no
pair with user namespace destruction, nor is their any ability for the
LSM to allocate any state to track the user namespace.  As there is no
patch actually calling audit or anything else observably does not appear
to be a driving factor of this new interface.


The common scenarios I am aware of for using the user namespace are:
- Creating a container.
- Using the user namespace to sandbox your application like chrome does.
- Running an exploit.

Returning an error code in the first 2 scenarios will create a userspace
regression as either userspace will run less securely or it won't work
at all.

Returning an error code in the third scenario when someone is trying to
exploit your machine is equally foolish as you are giving the exploit
the chance to continue running.  The application should be killed
instead.


Further adding a random failure mode to user namespace creation if it is
used at all will just encourage userspace to use a setuid application to
perform the namespace creation instead.  Creating a less secure system
overall.

If the concern is to reduce the attack surface everything this
proposed hook can do is already possible with the security_capable
security hook.

So Paul, Frederick please drop this.  I can't see what this new hook is
good for except creating regressions in existing userspace code.  I am
not willing to support such a hook in code that I maintain.

Eric