[bpf-next,02/29] bpf: add BPF token delegation mount options to BPF FS

Add few new mount options to BPF FS that allow to specify that a given
BPF FS instance allows creation of BPF token (added in the next patch),
and what sort of operations are allowed under BPF token. As such, we get
4 new mount options, each is a bit mask
  - `delegate_cmds` allow to specify which bpf() syscall commands are
    allowed with BPF token derived from this BPF FS instance;
  - if BPF_MAP_CREATE command is allowed, `delegate_maps` specifies
    a set of allowable BPF map types that could be created with BPF token;
  - if BPF_PROG_LOAD command is allowed, `delegate_progs` specifies
    a set of allowable BPF program types that could be loaded with BPF token;
  - if BPF_PROG_LOAD command is allowed, `delegate_attachs` specifies
    a set of allowable BPF program attach types that could be loaded with
    BPF token; delegate_progs and delegate_attachs are meant to be used
    together, as full BPF program type is, in general, determined
    through both program type and program attach type.

Currently, these mount options accept the following forms of values:
  - a special value "any", that enables all possible values of a given
  bit set;
  - numeric value (decimal or hexadecimal, determined by kernel
  automatically) that specifies a bit mask value directly;
  - all the values for a given mount option are combined, if specified
  multiple times. E.g., `mount -t bpf nodev /path/to/mount -o
  delegate_maps=0x1 -o delegate_maps=0x2` will result in a combined 0x3
  mask.

Ideally, more convenient (for humans) symbolic form derived from
corresponding UAPI enums would be accepted (e.g., `-o
delegate_progs=kprobe|tracepoint`) and I intend to implement this, but
it requires a bunch of UAPI header churn, so I postponed it until this
feature lands upstream or at least there is a definite consensus that
this feature is acceptable and is going to make it, just to minimize
amount of wasted effort and not increase amount of non-essential code to
be reviewed.

Attentive reader will notice that BPF FS is now marked as
FS_USERNS_MOUNT, which theoretically makes it mountable inside non-init
user namespace as long as the process has sufficient *namespaced*
capabilities within that user namespace. But in reality we still
restrict BPF FS to be mountable only by processes with CAP_SYS_ADMIN *in
init userns* (extra check in bpf_fill_super()). FS_USERNS_MOUNT is added
to allow creating BPF FS context object (i.e., fsopen("bpf")) from
inside unprivileged process inside non-init userns, to capture that
userns as the owning userns. It will still be required to pass this
context object back to privileged process to instantiate and mount it.

This manipulation is important, because capturing non-init userns as the
owning userns of BPF FS instance (super block) allows to use that userns
to constraint BPF token to that userns later on (see next patch). So
creating BPF FS with delegation inside unprivileged userns will restrict
derived BPF token objects to only "work" inside that intended userns,
making it scoped to a intended "container". Also, setting these
delegation options requires capable(CAP_SYS_ADMIN), so unprivileged
process cannot set this up without involvement of a privileged process.

There is a set of selftests at the end of the patch set that simulates
this sequence of steps and validates that everything works as intended.
But careful review is requested to make sure there are no missed gaps in
the implementation and testing.

This somewhat subtle set of aspects is the result of previous
discussions ([0]) about various user namespace implications and
interactions with BPF token functionality and is necessary to contain
BPF token inside intended user namespace.

  [0] https://lore.kernel.org/bpf/20230704-hochverdient-lehne-eeb9eeef785e@brauner/

Acked-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
---
 include/linux/bpf.h | 12 ++++++
 kernel/bpf/inode.c  | 90 +++++++++++++++++++++++++++++++++++++++------
 2 files changed, 90 insertions(+), 12 deletions(-)

Message ID	20240103222034.2582628-3-andrii@kernel.org (mailing list archive)
State	Changes Requested
Delegated to:	Paul Moore
Headers	show Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 25B581F607 for <linux-security-module@vger.kernel.org>; Wed, 3 Jan 2024 22:20:59 +0000 (UTC) From: Andrii Nakryiko <andrii@kernel.org> To: <bpf@vger.kernel.org>, <netdev@vger.kernel.org>, <paul@paul-moore.com>, <brauner@kernel.org>, <torvalds@linuxfoundation.org> CC: <linux-fsdevel@vger.kernel.org>, <linux-security-module@vger.kernel.org>, <kernel-team@meta.com> Subject: [PATCH bpf-next 02/29] bpf: add BPF token delegation mount options to BPF FS Date: Wed, 3 Jan 2024 14:20:07 -0800 Message-ID: <20240103222034.2582628-3-andrii@kernel.org> In-Reply-To: <20240103222034.2582628-1-andrii@kernel.org> References: <20240103222034.2582628-1-andrii@kernel.org> Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Precedence: bulk MIME-Version: 1.0
Series	BPF token \| expand [bpf-next,00/29] BPF token [bpf-next,01/29] bpf: align CAP_NET_ADMIN checks with bpf_capable() approach [bpf-next,02/29] bpf: add BPF token delegation mount options to BPF FS [bpf-next,03/29] bpf: introduce BPF token object [bpf-next,04/29] bpf: add BPF token support to BPF_MAP_CREATE command [bpf-next,05/29] bpf: add BPF token support to BPF_BTF_LOAD command [bpf-next,06/29] bpf: add BPF token support to BPF_PROG_LOAD command [bpf-next,07/29] bpf: take into account BPF token when fetching helper protos [bpf-next,08/29] bpf: consistently use BPF token throughout BPF verifier logic [bpf-next,09/29] bpf,lsm: refactor bpf_prog_alloc/bpf_prog_free LSM hooks [bpf-next,10/29] bpf,lsm: refactor bpf_map_alloc/bpf_map_free LSM hooks [bpf-next,11/29] bpf,lsm: add BPF token LSM hooks [bpf-next,12/29] libbpf: add bpf_token_create() API [bpf-next,13/29] libbpf: add BPF token support to bpf_map_create() API [bpf-next,14/29] libbpf: add BPF token support to bpf_btf_load() API [bpf-next,15/29] libbpf: add BPF token support to bpf_prog_load() API [bpf-next,16/29] selftests/bpf: add BPF token-enabled tests [bpf-next,17/29] bpf,selinux: allocate bpf_security_struct per BPF token [bpf-next,18/29] bpf: fail BPF_TOKEN_CREATE if no delegation option was set on BPF FS [bpf-next,19/29] bpf: support symbolic BPF FS delegation mount options [bpf-next,20/29] selftests/bpf: utilize string values for delegate_xxx mount options [bpf-next,21/29] libbpf: split feature detectors definitions from cached results [bpf-next,22/29] libbpf: further decouple feature checking logic from bpf_object [bpf-next,23/29] libbpf: move feature detection code into its own file [bpf-next,24/29] libbpf: wire up token_fd into feature probing logic [bpf-next,25/29] libbpf: wire up BPF token support at BPF object level [bpf-next,26/29] selftests/bpf: add BPF object loading tests with explicit token passing [bpf-next,27/29] selftests/bpf: add tests for BPF object load with implicit token [bpf-next,28/29] libbpf: support BPF token path setting through LIBBPF_BPF_TOKEN_PATH envvar [bpf-next,29/29] selftests/bpf: add tests for LIBBPF_BPF_TOKEN_PATH envvar

[bpf-next,02/29] bpf: add BPF token delegation mount options to BPF FS

Commit Message

Patch