From: Casey Schaufler <casey@schaufler-ca.com>
To: Jonathan Calmels <jcalmels@3xx0.net>,
Jarkko Sakkinen <jarkko@kernel.org>
Cc: 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,
Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [PATCH 0/3] Introduce user namespace capabilities
Date: Fri, 17 May 2024 10:53:24 -0700 [thread overview]
Message-ID: <df3c9e5c-b0e7-4502-8c36-c5cb775152c0@schaufler-ca.com> (raw)
In-Reply-To: <jvy3npdptyro3m2q2junvnokbq2fjlffljxeqitd55ff37cydc@b7mwtquys6im>
On 5/17/2024 4:42 AM, Jonathan Calmels wrote:
>>>> On Thu May 16, 2024 at 10:07 PM EEST, Casey Schaufler wrote:
>>>>> I suggest that adding a capability set for user namespaces is a bad idea:
>>>>> - It is in no way obvious what problem it solves
>>>>> - It is not obvious how it solves any problem
>>>>> - The capability mechanism has not been popular, and relying on a
>>>>> community (e.g. container developers) to embrace it based on this
>>>>> enhancement is a recipe for failure
>>>>> - Capabilities are already more complicated than modern developers
>>>>> want to deal with. Adding another, special purpose set, is going
>>>>> to make them even more difficult to use.
> Sorry if the commit wasn't clear enough.
While, as others have pointed out, the commit description left
much to be desired, that isn't the biggest problem with the change
you're proposing.
> Basically:
>
> - Today user namespaces grant full capabilities.
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.
> This behavior is often abused to attack various kernel subsystems.
Yes. The problems of a single, all powerful root privilege scheme are
well documented.
> Only option
Hardly.
> is to disable them altogether which breaks a lot of
> userspace stuff.
Updating userspace components to behave properly in a capabilities
environment has never been a popular activity, but is the right way
to address this issue. And before you start on the "no one can do that,
it's too hard", I'll point out that multiple UNIX systems supported
rootless, all capabilities based systems back in the day.
> This goes against the least privilege principle.
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.
>
> - It adds a new capability set.
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 set dictates what capabilities are granted in namespaces (instead
> of always getting full caps).
I would not expect container developers to be eager to learn how to use
this facility.
> This brings namespaces in line with the rest of the system, user
> namespaces are no more "special".
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.
>
> - This isn't intended to be used by end users per se (although they could).
> This would be used at the same places where existing capabalities are
> used today (e.g. init system, pam, container runtime, browser
> sandbox), or by system administrators.
I understand that. It is for containers. Containers are not kernel entities.
>
> To give you some ideas of things you could do:
>
> # E.g. prevent alice from getting CAP_NET_ADMIN in user namespaces under SSH
> echo "auth optional pam_cap.so" >> /etc/pam.d/sshd
> echo "!cap_net_admin alice" >> /etc/security/capability.conf.
>
> # E.g. prevent any Docker container from ever getting CAP_DAC_OVERRIDE
> systemd-run -p CapabilityBoundingSet=~CAP_DAC_OVERRIDE \
> -p SecureBits=userns-strict-caps \
> /usr/bin/dockerd
>
> # E.g. kernel could be vulnerable to CAP_SYS_RAWIO exploits
> # Prevent users from ever gaining it
> sysctl -w cap_bound_userns_mask=0x1fffffdffff
next prev parent reply other threads:[~2024-05-17 18:03 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 [this message]
2024-05-17 19:11 ` Jonathan Calmels
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=df3c9e5c-b0e7-4502-8c36-c5cb775152c0@schaufler-ca.com \
--to=casey@schaufler-ca.com \
--cc=brauner@kernel.org \
--cc=containers@lists.linux.dev \
--cc=dhowells@redhat.com \
--cc=ebiederm@xmission.com \
--cc=j.granados@samsung.com \
--cc=jarkko@kernel.org \
--cc=jcalmels@3xx0.net \
--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).