Received-SPF: pass (google.com: domain of linux-kernel+bounces-182553-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Feedback-ID: i76614979:Fastmail
Date: Fri, 17 May 2024 12:11:52 -0700
From: Jonathan Calmels <jcalmels@3xx0.net>
To: Casey Schaufler <casey@schaufler-ca.com>
Cc: Jarkko Sakkinen <jarkko@kernel.org>, brauner@kernel.org, 
	ebiederm@xmission.com, Luis Chamberlain <mcgrof@kernel.org>, 
	Kees Cook <keescook@chromium.org>, Joel Granados <j.granados@samsung.com>, 
	Serge Hallyn <serge@hallyn.com>, Paul Moore <paul@paul-moore.com>, 
	James Morris <jmorris@namei.org>, David Howells <dhowells@redhat.com>, containers@lists.linux.dev, 
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, 
	linux-security-module@vger.kernel.org, keyrings@vger.kernel.org
Subject: Re: [PATCH 0/3] Introduce user namespace capabilities
Message-ID: <vhpmew3kyay3xq4h3di3euauo43an22josvvz6assex4op3gzw@xeq63mqb2lmh>
References: <20240516092213.6799-1-jcalmels@3xx0.net>
 <2804dd75-50fd-481c-8867-bc6cea7ab986@schaufler-ca.com>
 <D1BBFWKGIA94.JP53QNURY3J4@kernel.org>
 <D1BBI1LX2FMW.3MTQAHW0MA1IH@kernel.org>
 <D1BC3VWXKTNC.2DB9JIIDOFIOQ@kernel.org>
 <jvy3npdptyro3m2q2junvnokbq2fjlffljxeqitd55ff37cydc@b7mwtquys6im>
 <df3c9e5c-b0e7-4502-8c36-c5cb775152c0@schaufler-ca.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <df3c9e5c-b0e7-4502-8c36-c5cb775152c0@schaufler-ca.com>

On Fri, May 17, 2024 at 10:53:24AM GMT, Casey Schaufler wrote:
> Of course they do. I have been following the use of capabilities
> in Linux since before they were implemented. The uptake has been
> disappointing in all use cases.

Why "Of course"?
What if they should not get *all* privileges?

> Yes. The problems of a single, all powerful root privilege scheme are
> well documented.

That's my point, it doesn't have to be this way.

> Hardly.

Maybe I'm missing something, then.
How do I restrict my users from gaining say CAP_NET_ADMIN in their
userns today?

> If you're going to run userspace that *requires* privilege, you have
> to have a way to *allow* privilege. If the userspace insists on a root
> based privilege model, you're stuck supporting it. Regardless of your
> principles.

I want *some* privileges, not *all* of them.

> Which is a really, really bad idea. The equation for calculating effective
> privilege is already more complicated than userspace developers are generally
> willing to put up with.

This is generally true, but this set is way more straightforward than
the other sets, it's always:

pU = pP = pE = X

If you look at the patch, there is no transition logic or anything
complicated, it's just a set of caps behind inherited.

> I would not expect container developers to be eager to learn how to use
> this facility.

And they probably wouldn't.
For most use cases it's going to be enforced through system policies
(init, pam, etc). Other than that, usage won't change, you will run your
usual `docker run --cap-add ...` to get caps, except now it works in
userns.

> I'm sorry, but this makes no sense to me whatsoever. You want to introduce
> a capability set explicitly for namespaces in order to make them less
> special? Maybe I'm just old and cranky.
> 
> >   They now work the same way as say a transition to root does with
> >   inheritable caps.
> 
> That needs some explanation.

From man capabilities(7):

In  order  to  mirror traditional UNIX semantics, the kernel performs
special treatment of file capabilities when a process with UID 0 (root)
executes a program [...]

Thus,  when [...] a process whose real and effective UIDs are
zero execve(2)s a program, the calculation of the process's new
permitted capabilities simplifies to:

   P'(permitted)   = P(inheritable) | P(bounding)

   P'(effective)   = P'(permitted)


So, the same way a root process is bounded by its inheritable set when
it execs, a "rootless" process is bounded by its userns set when it
unshares.