BPF List
 help / color / mirror / Atom feed
From: Jonathan Calmels <jcalmels@3xx0.net>
To: brauner@kernel.org,	ebiederm@xmission.com,
	Jonathan Corbet <corbet@lwn.net>,
	Paul Moore <paul@paul-moore.com>,
	James Morris <jmorris@namei.org>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	KP Singh <kpsingh@kernel.org>,
	Matt Bobrowski <mattbobrowski@google.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Eduard Zingerman <eddyz87@gmail.com>,	Song Liu <song@kernel.org>,
	Yonghong Song <yonghong.song@linux.dev>,
	John Fastabend <john.fastabend@gmail.com>,
	Stanislav Fomichev <sdf@google.com>,	Hao Luo <haoluo@google.com>,
	Jiri Olsa <jolsa@kernel.org>,
	Luis Chamberlain <mcgrof@kernel.org>, Kees Cook <kees@kernel.org>,
	Joel Granados <j.granados@samsung.com>,
	John Johansen <john.johansen@canonical.com>,
	David Howells <dhowells@redhat.com>,
	Jarkko Sakkinen <jarkko@kernel.org>,
	Stephen Smalley <stephen.smalley.work@gmail.com>,
	Ondrej Mosnacek <omosnace@redhat.com>,
	Mykola Lysenko <mykolal@fb.com>, Shuah Khan <shuah@kernel.org>
Cc: containers@lists.linux.dev, Jonathan Calmels <jcalmels@3xx0.net>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-security-module@vger.kernel.org,
	bpf@vger.kernel.org, apparmor@lists.ubuntu.com,
	keyrings@vger.kernel.org, selinux@vger.kernel.org,
	linux-kselftest@vger.kernel.org
Subject: [PATCH v2 0/4] Introduce user namespace capabilities
Date: Sun,  9 Jun 2024 03:43:33 -0700	[thread overview]
Message-ID: <20240609104355.442002-1-jcalmels@3xx0.net> (raw)

This patch series introduces a new user namespace capability set, as
well as some plumbing around it (i.e. sysctl, secbit, lsm support).

First patch goes over the motivations for this as well as prior art.

In summary, while user namespaces are a great success today in that they
avoid running a lot of code as root, they also expand the attack surface
of the kernel substantially which is often abused by attackers. 
Methods exist to limit the creation of such namespaces [1], however,
application developers often need to assume that user namespaces are
available for various tasks such as sandboxing. Thus, instead of
restricting the creation of user namespaces, we offer ways for userspace
to limit the capabilities granted to them.

Why a new capability set and not something specific to the userns (e.g.
ioctl_ns)?

    1. We can't really expect userspace to patch every single callsite
    and opt-in this new security mechanism. 

    2. We don't necessarily want policies enforced at said callsites.
    For example a service like systemd-machined or a PAM session need to
    be able to place restrictions on any namespace spawned under it.

    3. We would need to come up with inheritance rules, querying
    capabilities, etc. At this point we're just reinventing capability
    sets.

    4. We can easily define interactions between capability sets, thus
    helping with adoption (patch 2 is an example of this)

Some examples of how this could be leveraged in userspace:

    - Prevent user from getting CAP_NET_ADMIN in user namespaces under SSH:
        echo "auth optional pam_cap.so" >> /etc/pam.d/sshd
        echo "!cap_net_admin $USER"     >> /etc/security/capability.conf
        capsh --secbits=$((1 << 8)) -- -c /usr/sbin/sshd

    - Prevent containers from ever getting CAP_DAC_OVERRIDE:
        systemd-run -p CapabilityBoundingSet=~CAP_DAC_OVERRIDE \
                    -p SecureBits=userns-strict-caps \
                    /usr/bin/dockerd
        systemd-run -p UserNSCapabilities=~CAP_DAC_OVERRIDE \
                    /usr/bin/incusd

    - Kernel could be vulnerable to CAP_SYS_RAWIO exploits, prevent it:
        sysctl -w cap_bound_userns_mask=0x1fffffdffff

    - Drop CAP_SYS_ADMIN for this shell and all the user namespaces below it:
        bwrap --unshare-user --cap-drop CAP_SYS_ADMIN /bin/sh

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7cd4c5c2101cb092db00f61f69d24380cf7a0ee8

---
Changes since v1:
- Add documentation
- Change commit wording
- Cleanup various aspects of the code based on feedback
- Add new CAP_SYS_CONTROL capability for sysctl check
- Add BPF-LSM support for modifying userns capabilities
---
Jonathan Calmels (4):
  capabilities: Add user namespace capabilities
  capabilities: Add securebit to restrict userns caps
  capabilities: Add sysctl to mask off userns caps
  bpf,lsm: Allow editing capabilities in BPF-LSM hooks

 Documentation/filesystems/proc.rst            |  1 +
 Documentation/security/credentials.rst        |  6 ++
 fs/proc/array.c                               |  9 +++
 include/linux/cred.h                          |  3 +
 include/linux/lsm_hook_defs.h                 |  2 +-
 include/linux/securebits.h                    |  1 +
 include/linux/security.h                      |  4 +-
 include/linux/user_namespace.h                |  7 ++
 include/uapi/linux/capability.h               |  6 +-
 include/uapi/linux/prctl.h                    |  7 ++
 include/uapi/linux/securebits.h               | 11 ++-
 kernel/bpf/bpf_lsm.c                          | 55 +++++++++++++
 kernel/cred.c                                 |  3 +
 kernel/sysctl.c                               | 10 +++
 kernel/umh.c                                  | 15 ++++
 kernel/user_namespace.c                       | 80 +++++++++++++++++--
 security/apparmor/lsm.c                       |  2 +-
 security/commoncap.c                          | 62 +++++++++++++-
 security/keys/process_keys.c                  |  3 +
 security/security.c                           |  6 +-
 security/selinux/hooks.c                      |  2 +-
 security/selinux/include/classmap.h           |  5 +-
 .../selftests/bpf/prog_tests/deny_namespace.c | 12 ++-
 .../selftests/bpf/progs/test_deny_namespace.c |  7 +-
 24 files changed, 291 insertions(+), 28 deletions(-)

-- 
2.45.2


             reply	other threads:[~2024-06-09 10:39 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-09 10:43 Jonathan Calmels [this message]
2024-06-09 10:43 ` [PATCH v2 1/4] capabilities: Add user namespace capabilities Jonathan Calmels
2024-06-10  1:50   ` Serge E. Hallyn
2024-06-10  8:47     ` Jonathan Calmels
2024-06-10 12:48       ` Serge E. Hallyn
2024-06-10 13:00   ` Serge E. Hallyn
2024-06-11  8:20     ` Jonathan Calmels
2024-06-15 15:19       ` Serge E. Hallyn
2024-06-09 10:43 ` [PATCH v2 2/4] capabilities: Add securebit to restrict userns caps Jonathan Calmels
2024-06-10  2:33   ` Serge E. Hallyn
2024-06-10  9:46     ` Jonathan Calmels
2024-06-10 13:05       ` Serge E. Hallyn
2024-06-28 14:43   ` Jarkko Sakkinen
2024-06-28 14:45     ` Jarkko Sakkinen
2024-06-09 10:43 ` [PATCH v2 3/4] capabilities: Add sysctl to mask off " Jonathan Calmels
2024-06-09 10:43 ` [PATCH v2 4/4] bpf,lsm: Allow editing capabilities in BPF-LSM hooks Jonathan Calmels
2024-06-10  0:18   ` Paul Moore
2024-06-11  8:09     ` Jonathan Calmels
2024-06-11 10:31       ` John Johansen
2024-06-11 19:01         ` Paul Moore
2024-06-11 22:20           ` Jonathan Calmels
2024-06-11 22:38             ` Paul Moore
2024-06-12  8:20               ` Jonathan Calmels
2024-06-12 17:29                 ` Paul Moore
2024-06-13  3:54                   ` John Johansen
2024-06-13  8:50                     ` Jonathan Calmels
2024-06-13 20:55                       ` Paul Moore
2024-06-15 15:20                       ` Serge E. Hallyn
2024-06-13 10:45                     ` Dr. Greg
2024-06-13 20:43                     ` Paul Moore
2024-06-10 20:12 ` [PATCH v2 0/4] Introduce user namespace capabilities Josef Bacik
2024-06-11  8:33   ` Jonathan Calmels

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=20240609104355.442002-1-jcalmels@3xx0.net \
    --to=jcalmels@3xx0.net \
    --cc=andrii@kernel.org \
    --cc=apparmor@lists.ubuntu.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brauner@kernel.org \
    --cc=containers@lists.linux.dev \
    --cc=corbet@lwn.net \
    --cc=daniel@iogearbox.net \
    --cc=dhowells@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=eddyz87@gmail.com \
    --cc=haoluo@google.com \
    --cc=j.granados@samsung.com \
    --cc=jarkko@kernel.org \
    --cc=jmorris@namei.org \
    --cc=john.fastabend@gmail.com \
    --cc=john.johansen@canonical.com \
    --cc=jolsa@kernel.org \
    --cc=kees@kernel.org \
    --cc=keyrings@vger.kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=mattbobrowski@google.com \
    --cc=mcgrof@kernel.org \
    --cc=mykolal@fb.com \
    --cc=omosnace@redhat.com \
    --cc=paul@paul-moore.com \
    --cc=sdf@google.com \
    --cc=selinux@vger.kernel.org \
    --cc=serge@hallyn.com \
    --cc=shuah@kernel.org \
    --cc=song@kernel.org \
    --cc=stephen.smalley.work@gmail.com \
    --cc=yonghong.song@linux.dev \
    /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