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
Date: Fri, 17 May 2024 12:11:52 -0700 [thread overview]
Message-ID: <vhpmew3kyay3xq4h3di3euauo43an22josvvz6assex4op3gzw@xeq63mqb2lmh> (raw)
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.
next prev parent reply other threads:[~2024-05-17 19:06 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-16 9:22 [PATCH 0/3] Introduce user namespace capabilities Jonathan Calmels
2024-05-16 9:22 ` [PATCH 1/3] capabilities: " Jonathan Calmels
2024-05-16 12:27 ` Jarkko Sakkinen
2024-05-16 22:07 ` John Johansen
2024-05-17 10:51 ` Jonathan Calmels
2024-05-17 11:59 ` John Johansen
2024-05-18 3:50 ` Jonathan Calmels
2024-05-18 12:27 ` John Johansen
2024-05-19 1:33 ` Jonathan Calmels
2024-05-17 11:32 ` Eric W. Biederman
2024-05-17 11:55 ` Jonathan Calmels
2024-05-17 12:48 ` John Johansen
2024-05-17 14:22 ` Eric W. Biederman
2024-05-17 18:02 ` Jonathan Calmels
2024-05-21 15:52 ` John Johansen
2024-05-20 3:30 ` Serge E. Hallyn
2024-05-20 3:36 ` Serge E. Hallyn
2024-05-16 9:22 ` [PATCH 2/3] capabilities: add securebit for strict userns caps Jonathan Calmels
2024-05-16 12:42 ` Jarkko Sakkinen
2024-05-20 3:38 ` Serge E. Hallyn
2024-05-16 9:22 ` [PATCH 3/3] capabilities: add cap userns sysctl mask Jonathan Calmels
2024-05-16 12:44 ` Jarkko Sakkinen
2024-05-20 3:38 ` Serge E. Hallyn
2024-05-20 13:30 ` Tycho Andersen
2024-05-20 19:25 ` Jonathan Calmels
2024-05-20 21:13 ` Tycho Andersen
2024-05-20 22:12 ` Jarkko Sakkinen
2024-05-21 14:29 ` Tycho Andersen
2024-05-21 14:45 ` Jarkko Sakkinen
2024-05-16 13:30 ` [PATCH 0/3] Introduce user namespace capabilities Ben Boeckel
2024-05-16 13:36 ` Jarkko Sakkinen
2024-05-17 10:00 ` Jonathan Calmels
2024-05-16 16:23 ` Paul Moore
2024-05-16 17:18 ` Jarkko Sakkinen
2024-05-16 19:07 ` Casey Schaufler
2024-05-16 19:29 ` Jarkko Sakkinen
2024-05-16 19:31 ` Jarkko Sakkinen
2024-05-16 20:00 ` Jarkko Sakkinen
2024-05-17 11:42 ` Jonathan Calmels
2024-05-17 17:53 ` Casey Schaufler
2024-05-17 19:11 ` Jonathan Calmels [this message]
2024-05-18 11:08 ` Jarkko Sakkinen
2024-05-18 11:17 ` Jarkko Sakkinen
2024-05-18 11:21 ` Jarkko Sakkinen
2024-05-21 13:57 ` John Johansen
2024-05-21 14:12 ` Jarkko Sakkinen
2024-05-21 14:45 ` John Johansen
2024-05-22 0:45 ` Jonathan Calmels
2024-05-31 7:43 ` John Johansen
2024-05-18 12:20 ` Serge Hallyn
2024-05-19 17:03 ` Casey Schaufler
2024-05-20 0:54 ` Jonathan Calmels
2024-05-21 14:29 ` John Johansen
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=vhpmew3kyay3xq4h3di3euauo43an22josvvz6assex4op3gzw@xeq63mqb2lmh \
--to=jcalmels@3xx0.net \
--cc=brauner@kernel.org \
--cc=casey@schaufler-ca.com \
--cc=containers@lists.linux.dev \
--cc=dhowells@redhat.com \
--cc=ebiederm@xmission.com \
--cc=j.granados@samsung.com \
--cc=jarkko@kernel.org \
--cc=jmorris@namei.org \
--cc=keescook@chromium.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mcgrof@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).