From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
Christian Brauner <brauner@kernel.org>
Cc: Paul Moore <paul@paul-moore.com>,
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 01/14] bpf: introduce BPF token object
Date: Thu, 06 Jul 2023 13:32:42 +0200 [thread overview]
Message-ID: <87a5w9s2at.fsf@toke.dk> (raw)
In-Reply-To: <CAEf4Bza5mUou8nw1zjqFaCPPvfUNq-jpNp+y4DhMhhcXc5HwGg@mail.gmail.com>
Andrii Nakryiko <andrii.nakryiko@gmail.com> writes:
> Having it as a separate single-purpose FS seems cleaner, because we
> have use cases where we'd have one BPF FS instance created for a
> container by our container manager, and then exposing a few separate
> tokens with different sets of allowed functionality. E.g., one for
> main intended workload, another for some BPF-based observability
> tools, maybe yet another for more heavy-weight tools like bpftrace for
> extra debugging. In the debugging case our container infrastructure
> will be "evacuating" any other workloads on the same host to avoid
> unnecessary consequences. The point is to not disturb
> workload-under-human-debugging as much as possible, so we'd like to
> keep userns intact, which is why mounting extra (more permissive) BPF
> token inside already running containers is an important consideration.
This example (as well as Yafang's in the sibling subthread) makes it
even more apparent to me that it would be better with a model where the
userspace policy daemon can just make decisions on each call directly,
instead of mucking about with different tokens with different embedded
permissions. Why not go that route (see my other reply for details on
what I mean)?
-Toke
next prev parent reply other threads:[~2023-07-06 11: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 [this message]
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
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=87a5w9s2at.fsf@toke.dk \
--to=toke@redhat.com \
--cc=andrii.nakryiko@gmail.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=paul@paul-moore.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox