From: Jonathan Calmels <jcalmels@3xx0.net>
To: Jarkko Sakkinen <jarkko@kernel.org>
Cc: Casey Schaufler <casey@schaufler-ca.com>,
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 04:42:02 -0700 [thread overview]
Message-ID: <jvy3npdptyro3m2q2junvnokbq2fjlffljxeqitd55ff37cydc@b7mwtquys6im> (raw)
In-Reply-To: <D1BC3VWXKTNC.2DB9JIIDOFIOQ@kernel.org>
> > > 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. Basically:
- Today user namespaces grant full capabilities.
This behavior is often abused to attack various kernel subsystems.
Only option is to disable them altogether which breaks a lot of
userspace stuff.
This goes against the least privilege principle.
- It adds a new capability set.
This set dictates what capabilities are granted in namespaces (instead
of always getting full caps).
This brings namespaces in line with the rest of the system, user
namespaces are no more "special".
They now work the same way as say a transition to root does with
inheritable caps.
- 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.
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 11:37 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 [this message]
2024-05-17 17:53 ` Casey Schaufler
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=jvy3npdptyro3m2q2junvnokbq2fjlffljxeqitd55ff37cydc@b7mwtquys6im \
--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).