From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Christian Brauner <brauner@kernel.org>
Cc: Andrii Nakryiko <andrii@kernel.org>,
bpf@vger.kernel.org, linux-security-module@vger.kernel.org,
keescook@chromium.org, lennart@poettering.net, cyphar@cyphar.com,
luto@kernel.org, kernel-team@meta.com, sargun@sargun.me
Subject: Re: [PATCH RESEND v3 bpf-next 00/14] BPF token
Date: Wed, 05 Jul 2023 01:33:28 +0200 [thread overview]
Message-ID: <87pm57b6bb.fsf@toke.dk> (raw)
In-Reply-To: <20230704-vielversprechend-zollfrei-a2a148f2699b@brauner>
Christian Brauner <brauner@kernel.org> writes:
> On Fri, Jun 30, 2023 at 01:15:47AM +0200, Toke Høiland-Jørgensen wrote:
>> Andrii Nakryiko <andrii@kernel.org> writes:
>>
>> > This patch set introduces new BPF object, BPF token, which allows to delegate
>> > a subset of BPF functionality from privileged system-wide daemon (e.g.,
>> > systemd or any other container manager) to a *trusted* unprivileged
>> > application. Trust is the key here. This functionality is not about allowing
>> > unconditional unprivileged BPF usage. Establishing trust, though, is
>> > completely up to the discretion of respective privileged application that
>> > would create a BPF token, as different production setups can and do achieve it
>> > through a combination of different means (signing, LSM, code reviews, etc),
>> > and it's undesirable and infeasible for kernel to enforce any particular way
>> > of validating trustworthiness of particular process.
>> >
>> > The main motivation for BPF token is a desire to enable containerized
>> > BPF applications to be used together with user namespaces. This is currently
>> > impossible, as CAP_BPF, required for BPF subsystem usage, cannot be namespaced
>> > or sandboxed, as a general rule. E.g., tracing BPF programs, thanks to BPF
>> > helpers like bpf_probe_read_kernel() and bpf_probe_read_user() can safely read
>> > arbitrary memory, and it's impossible to ensure that they only read memory of
>> > processes belonging to any given namespace. This means that it's impossible to
>> > have namespace-aware CAP_BPF capability, and as such another mechanism to
>> > allow safe usage of BPF functionality is necessary. BPF token and delegation
>> > of it to a trusted unprivileged applications is such mechanism. Kernel makes
>> > no assumption about what "trusted" constitutes in any particular case, and
>> > it's up to specific privileged applications and their surrounding
>> > infrastructure to decide that. What kernel provides is a set of APIs to create
>> > and tune BPF token, and pass it around to privileged BPF commands that are
>> > creating new BPF objects like BPF programs, BPF maps, etc.
>>
>> So a colleague pointed out today that the Seccomp Notify functionality
>> would be a way to achieve your stated goal of allowing unprivileged
>> containers to (selectively) perform bpf() syscall operations. Christian
>> Brauner has a pretty nice writeup of the functionality here:
>> https://people.kernel.org/brauner/the-seccomp-notifier-new-frontiers-in-unprivileged-container-development
>
> I'm amazed you read this. :)
I found it quite an enjoyable read, actually :)
> The seccomp notifier comes with a lot of caveats. I think it would be
> impractical if not infeasible to handle bpf() delegation.
Right, thank you for chiming in and explaining the context. I replied
elsewhere in the thread on the content, so let's not fork the discussion
any more than we have to...
-Toke
next prev parent reply other threads:[~2023-07-04 23:33 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-29 5:18 [PATCH RESEND v3 bpf-next 00/14] BPF token Andrii Nakryiko
2023-06-29 5:18 ` [PATCH RESEND v3 bpf-next 01/14] bpf: introduce BPF token object Andrii Nakryiko
2023-07-04 12:43 ` Christian Brauner
2023-07-04 13:34 ` Christian Brauner
2023-07-04 23:28 ` Toke Høiland-Jørgensen
2023-07-05 7:20 ` Daniel Borkmann
2023-07-05 8:45 ` Christian Brauner
2023-07-05 12:34 ` Toke Høiland-Jørgensen
2023-07-05 14:16 ` Paul Moore
2023-07-05 14:42 ` Christian Brauner
2023-07-05 16:00 ` Paul Moore
2023-07-05 21:38 ` Andrii Nakryiko
2023-07-06 11:32 ` Toke Høiland-Jørgensen
2023-07-06 20:37 ` Andrii Nakryiko
2023-07-07 13:04 ` Toke Høiland-Jørgensen
2023-07-07 17:58 ` Andrii Nakryiko
2023-07-07 22:00 ` Toke Høiland-Jørgensen
2023-07-07 23:58 ` Andrii Nakryiko
2023-07-10 23:42 ` Djalal Harouni
2023-07-11 13:33 ` Christian Brauner
2023-07-11 22:06 ` Andrii Nakryiko
2023-06-29 5:18 ` [PATCH RESEND v3 bpf-next 02/14] libbpf: add bpf_token_create() API Andrii Nakryiko
2023-06-29 5:18 ` [PATCH RESEND v3 bpf-next 03/14] selftests/bpf: add BPF_TOKEN_CREATE test Andrii Nakryiko
2023-06-29 5:18 ` [PATCH RESEND v3 bpf-next 04/14] bpf: add BPF token support to BPF_MAP_CREATE command Andrii Nakryiko
2023-06-29 5:18 ` [PATCH RESEND v3 bpf-next 05/14] libbpf: add BPF token support to bpf_map_create() API Andrii Nakryiko
2023-06-29 5:18 ` [PATCH RESEND v3 bpf-next 06/14] selftests/bpf: add BPF token-enabled test for BPF_MAP_CREATE command Andrii Nakryiko
2023-06-29 5:18 ` [PATCH RESEND v3 bpf-next 07/14] bpf: add BPF token support to BPF_BTF_LOAD command Andrii Nakryiko
2023-06-29 5:18 ` [PATCH RESEND v3 bpf-next 08/14] libbpf: add BPF token support to bpf_btf_load() API Andrii Nakryiko
2023-06-29 5:18 ` [PATCH RESEND v3 bpf-next 09/14] selftests/bpf: add BPF token-enabled BPF_BTF_LOAD selftest Andrii Nakryiko
2023-06-29 5:18 ` [PATCH RESEND v3 bpf-next 10/14] bpf: add BPF token support to BPF_PROG_LOAD command Andrii Nakryiko
2023-06-29 5:18 ` [PATCH RESEND v3 bpf-next 11/14] bpf: take into account BPF token when fetching helper protos Andrii Nakryiko
2023-06-29 5:18 ` [PATCH RESEND v3 bpf-next 12/14] bpf: consistenly use BPF token throughout BPF verifier logic Andrii Nakryiko
2023-06-29 5:18 ` [PATCH RESEND v3 bpf-next 13/14] libbpf: add BPF token support to bpf_prog_load() API Andrii Nakryiko
2023-06-29 5:18 ` [PATCH RESEND v3 bpf-next 14/14] selftests/bpf: add BPF token-enabled BPF_PROG_LOAD tests Andrii Nakryiko
2023-06-29 23:15 ` [PATCH RESEND v3 bpf-next 00/14] BPF token Toke Høiland-Jørgensen
2023-06-30 18:25 ` Andrii Nakryiko
2023-07-04 9:38 ` Christian Brauner
2023-07-04 23:20 ` Toke Høiland-Jørgensen
2023-07-05 12:57 ` Stefano Brivio
2023-07-02 6:59 ` Djalal Harouni
2023-07-04 9:51 ` Christian Brauner
2023-07-04 23:33 ` Toke Høiland-Jørgensen [this message]
2023-07-05 20:39 ` Andrii Nakryiko
2023-07-01 2:05 ` Yafang Shao
2023-07-05 20:37 ` Andrii Nakryiko
2023-07-06 1:26 ` Yafang Shao
2023-07-06 20:34 ` Andrii Nakryiko
2023-07-07 1:42 ` Yafang Shao
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=87pm57b6bb.fsf@toke.dk \
--to=toke@redhat.com \
--cc=andrii@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=cyphar@cyphar.com \
--cc=keescook@chromium.org \
--cc=kernel-team@meta.com \
--cc=lennart@poettering.net \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@kernel.org \
--cc=sargun@sargun.me \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.